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
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 |