lock_timeout GUC patch
in [PgSql]
|
From: Boszormenyi Zoltan on 20 Jan 2010 04:29 Tom Lane �rta: > Boszormenyi Zoltan <zb(a)cybertec.at> writes: > >> [ 5-pg85-locktimeout-14-ctxdiff.patch ] >> > > I took a quick look at this. I am not qualified to review the Win32 > implementation of PGSemaphoreTimedLock, but I am afraid that both of > the other ones are nonstarters on portability grounds. sem_timedwait() > and semtimedop() do not appear in the Single Unix Spec, which is our > usual reference for what is portable. In particular I don't see either > of them on OS X or HPUX. We're lucky in that regard, we have developed and tested this patch under Linux and: # uname -a HP-UX uxhv1f17 B.11.31 U ia64 4099171317 unlimited-user license The links under src/backend/port show that it uses sysv_sema.c and semtimedop() compiles and works nicely there. Hans will test it under OS X. > I suspect that applying this patch would > immediately break every platform except Linux. > Fortunately suspicion doesn not mean guilty, let's wait for Hans' test. > I also concur with Alvaro's feeling that the changes to XactLockTableWait() > and MultiXactIdWait() are inappropriate. There is no reason to assume > that there is always a relevant relation for waits performed with those > functions. (In the same line, not all of the added error reports are > careful about what happens if get_rel_name fails.) > Okay, I don't have strong feelings about the exact error message, I will post the older version with the Lock* APIs intact, add the chunk that adds the GUC to postgresql.conf.sample and also look at your comment. But IIRC some of the missing checks come from the callers' logic, they (all or only some of them? have to check) already opened the Relation they try to lock hence the same get_rel_name() MUST succeed or else it's an internal error already. > A larger question, which I think has been raised before but I have not > seen a satisfactory answer for, is whether the system will behave sanely > at all with this type of patch in place. I don't really think that a > single lock timeout applicable to every possible reason to wait is going > to be nice to use; IIRC you were the one who raised the issue but in the exact opposite way to conclude that we won't need SELECT ... WAIT N to complement NOWAIT. Stick to one opinion please. :-) > and I'm afraid in some contexts it could render > things completely nonfunctional. (In particular I think that Hot > Standby is fragile enough already without this.) It seems particularly > imprudent to make such a thing USERSET, implying that any clueless or > malicious user could set it in a way that would cause problems, if there > are any to cause. > Is there an flag that causes the setting rejected from postgresql.conf but makes settable from the session? This would ensure correct operation, as the default 0 behaves the same as before. Best regards, Zolt�n B�sz�rm�nyi -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil." (Matthew 5:37) - basics of digital technology. "May your kingdom come" - superficial description of plate tectonics ---------------------------------- Zolt�n B�sz�rm�nyi Cybertec Sch�nig & Sch�nig GmbH http://www.postgresql.at/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Boszormenyi Zoltan on 20 Jan 2010 05:23 Tom Lane �rta: > Greg Stark <stark(a)mit.edu> writes: > >> we already have statement timeout it seems the natural easy to implement >> this is with more hairy logic to calculate the timeout until the next of the >> three timeouts should fire and set sigalarm. I sympathize with whoever tries >> to work that through though, the logic is hairy enough with just the two >> variables...but at least we know that sigalarm works or at least it had >> better... >> > > Yeah, that code is ugly as sin already. Maybe there is a way to > refactor it so it can scale better? I can't help thinking of Polya's > inventor's paradox ("the more general problem may be easier to solve"). > > If we want to do it without any new system-call dependencies I think > that's probably the only way. I'm not necessarily against new > dependencies, if they're portable --- but it seems these aren't. > Okay, after reading google it seems you're right that OS X lacks sem_timedwait(). How about adding a configure check for semtimedop() and sem_timedwait() and if they don't exist set a compile time flag (HAVE_XXX) and in this case PGSemaphoreTimedLock() would behave the same as PGSemaphoreLock() and have an assign_*() function that tells the user that the timeout functionality is missing? We have precedent for the missing functionality with e.g. effective_io_concurrency and ereport() is also allowed in such functions, see assign_transaction_read_only(). Best regards, Zolt�n B�sz�rm�nyi -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil." (Matthew 5:37) - basics of digital technology. "May your kingdom come" - superficial description of plate tectonics ---------------------------------- Zolt�n B�sz�rm�nyi Cybertec Sch�nig & Sch�nig GmbH http://www.postgresql.at/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Boszormenyi Zoltan on 20 Jan 2010 07:11 Boszormenyi Zoltan �rta: > Tom Lane �rta: > >> Greg Stark <stark(a)mit.edu> writes: >> >> >>> we already have statement timeout it seems the natural easy to implement >>> this is with more hairy logic to calculate the timeout until the next of the >>> three timeouts should fire and set sigalarm. I sympathize with whoever tries >>> to work that through though, the logic is hairy enough with just the two >>> variables...but at least we know that sigalarm works or at least it had >>> better... >>> >>> >> Yeah, that code is ugly as sin already. Maybe there is a way to >> refactor it so it can scale better? I can't help thinking of Polya's >> inventor's paradox ("the more general problem may be easier to solve"). >> >> If we want to do it without any new system-call dependencies I think >> that's probably the only way. I'm not necessarily against new >> dependencies, if they're portable --- but it seems these aren't. >> >> > > Okay, after reading google it seems you're right that OS X lacks > sem_timedwait(). How about adding a configure check for semtimedop() > and sem_timedwait() and if they don't exist set a compile time flag > (HAVE_XXX) and in this case PGSemaphoreTimedLock() would > behave the same as PGSemaphoreLock() and have an assign_*() > function that tells the user that the timeout functionality is missing? > We have precedent for the missing functionality with e.g. > effective_io_concurrency and ereport() is also allowed in such > functions, see assign_transaction_read_only(). > Attached with the proposed modification to lift the portability concerns. Fixed the missing check for get_rel_name() and one typo ("transation") Introduced checks for semtimedop() and sem_timedwait() in configure.in and USE_LOCK_TIMEOUT in port.h depending on HAVE_DECL_SEMTIMEDOP || HAVE_DECL_SEM_TIMEDWAIT || WIN32 Introduced assign_lock_timeout() GUC validator function that allows setting the value only from the wired-in-default (0) or from SET statements. Comments? Best regards, Zolt�n B�sz�rm�nyi -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil." (Matthew 5:37) - basics of digital technology. "May your kingdom come" - superficial description of plate tectonics ---------------------------------- Zolt�n B�sz�rm�nyi Cybertec Sch�nig & Sch�nig GmbH http://www.postgresql.at/
From: Jaime Casanova on 20 Jan 2010 09:54 If that's the case then others timeouts should be failing on os x, no? But i have never hear that 2010/1/20, Boszormenyi Zoltan <zb(a)cybertec.at>: > Boszormenyi Zoltan Ãrta: >> Tom Lane Ãrta: >> >>> Greg Stark <stark(a)mit.edu> writes: >>> >>> >>>> we already have statement timeout it seems the natural easy to implement >>>> this is with more hairy logic to calculate the timeout until the next of >>>> the >>>> three timeouts should fire and set sigalarm. I sympathize with whoever >>>> tries >>>> to work that through though, the logic is hairy enough with just the two >>>> variables...but at least we know that sigalarm works or at least it had >>>> better... >>>> >>>> >>> Yeah, that code is ugly as sin already. Maybe there is a way to >>> refactor it so it can scale better? I can't help thinking of Polya's >>> inventor's paradox ("the more general problem may be easier to solve"). >>> >>> If we want to do it without any new system-call dependencies I think >>> that's probably the only way. I'm not necessarily against new >>> dependencies, if they're portable --- but it seems these aren't. >>> >>> >> >> Okay, after reading google it seems you're right that OS X lacks >> sem_timedwait(). How about adding a configure check for semtimedop() >> and sem_timedwait() and if they don't exist set a compile time flag >> (HAVE_XXX) and in this case PGSemaphoreTimedLock() would >> behave the same as PGSemaphoreLock() and have an assign_*() >> function that tells the user that the timeout functionality is missing? >> We have precedent for the missing functionality with e.g. >> effective_io_concurrency and ereport() is also allowed in such >> functions, see assign_transaction_read_only(). >> > > Attached with the proposed modification to lift the portability concerns. > Fixed the missing check for get_rel_name() and one typo ("transation") > Introduced checks for semtimedop() and sem_timedwait() in configure.in > and USE_LOCK_TIMEOUT in port.h depending on > HAVE_DECL_SEMTIMEDOP || HAVE_DECL_SEM_TIMEDWAIT || WIN32 > Introduced assign_lock_timeout() GUC validator function that allows > setting the value only from the wired-in-default (0) or from SET statements. > > Comments? > > Best regards, > Zoltán Böszörményi > > -- > Bible has answers for everything. Proof: > "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more > than these cometh of evil." (Matthew 5:37) - basics of digital technology. > "May your kingdom come" - superficial description of plate tectonics > > ---------------------------------- > Zoltán Böszörményi > Cybertec Schönig & Schönig GmbH > http://www.postgresql.at/ > > -- Enviado desde mi dispositivo móvil Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL AsesorÃa y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Boszormenyi Zoltan on 20 Jan 2010 10:00
Hi, I wrote: > Okay, after reading google it seems you're right that OS X lacks > sem_timedwait(). Jaime Casanova írta: > If that's the case then others timeouts should be failing on os x, no? > But i have never hear that > among others, I found this reference on the missing sem_timedwait() function: http://bugs.freepascal.org/view.php?id=13148 Best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil." (Matthew 5:37) - basics of digital technology. "May your kingdom come" - superficial description of plate tectonics ---------------------------------- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH http://www.postgresql.at/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |