lock_timeout GUC patch
in [PgSql]
|
From: Robert Haas on 19 Jan 2010 18:55 On Tue, Jan 19, 2010 at 6:40 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > 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; 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. The obvious alternative is to have specific syntax to allow for waits on specific types of statements; however, based on the previous round of conversation, I thought we had concluded that the present design was the least of evils. http://archives.postgresql.org/pgsql-hackers/2009-09/msg01730.php I am not too sure what you think this might break? ....Robert -- 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: Tom Lane on 19 Jan 2010 19:10 Robert Haas <robertmhaas(a)gmail.com> writes: > On Tue, Jan 19, 2010 at 6:40 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> 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 am not too sure what you think this might break? I'm not sure either. If we weren't at the tail end of a devel cycle, with a large/destabilizing patch already in there that has a great deal of exposure to details of locking behavior, I'd not be so worried. Maybe the right thing is to bounce this back to be reconsidered in the first fest of the next cycle. It's not ready to commit anyway because of the portability problems, so ... regards, tom lane -- 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: Robert Haas on 19 Jan 2010 19:27 On Tue, Jan 19, 2010 at 7:10 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> On Tue, Jan 19, 2010 at 6:40 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >>> 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 am not too sure what you think this might break? > > I'm not sure either. If we weren't at the tail end of a devel cycle, > with a large/destabilizing patch already in there that has a great deal > of exposure to details of locking behavior, I'd not be so worried. > > Maybe the right thing is to bounce this back to be reconsidered in the > first fest of the next cycle. It's not ready to commit anyway because > of the portability problems, so ... That seems reasonable to me. I'd like to have the functionality, but pushing it off a release sounds reasonable, if we're worried that it will be destabilizing. ....Robert -- 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: Greg Stark on 19 Jan 2010 20:54 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... greg On 20 Jan 2010 00:27, "Robert Haas" <robertmhaas(a)gmail.com> wrote: On Tue, Jan 19, 2010 at 7:10 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmai... That seems reasonable to me. I'd like to have the functionality, but pushing it off a release sounds reasonable, if we're worried that it will be destabilizing. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subs...
From: Tom Lane on 19 Jan 2010 22:07
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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |