Re: lock_timeout GUC patch - Mailing list pgsql-hackers

From Robert Haas
Subject Re: lock_timeout GUC patch
Date
Msg-id 603c8f071001191627s43e5d36fid96b8014edb0afea@mail.gmail.com
Whole thread Raw
In response to Re: lock_timeout GUC patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: lock_timeout GUC patch  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
On Tue, Jan 19, 2010 at 7:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, Jan 19, 2010 at 6:40 PM, Tom Lane <tgl@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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Listen / Notify - what to do when the queue is full
Next
From: Jeff Davis
Date:
Subject: Re: Listen / Notify - what to do when the queue is full