Re: lock_timeout GUC patch

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Boszormenyi Zoltan <zb(at)cybertec(dot)at>, Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: lock_timeout GUC patch
Date: 2010-01-20 00:27:16
Message-ID: 603c8f071001191627s43e5d36fid96b8014edb0afea@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 19, 2010 at 7:10 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Jan 19, 2010 at 6:40 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2010-01-20 00:29:03 Re: Listen / Notify - what to do when the queue is full
Previous Message Tom Lane 2010-01-20 00:24:19 Re: Listen / Notify - what to do when the queue is full