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-19 23:55:08 |
Message-ID: | 603c8f071001191555n47916563l6294ec9ba34e33e4@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 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
From | Date | Subject | |
---|---|---|---|
Next Message | David Christensen | 2010-01-20 00:01:29 | Patch rev 2: MySQL-ism help patch for psql |
Previous Message | Jeff Davis | 2010-01-19 23:41:29 | Re: Listen / Notify - what to do when the queue is full |