Re: lock_timeout GUC patch - Mailing list pgsql-hackers

From Robert Haas
Subject Re: lock_timeout GUC patch
Date
Msg-id 603c8f071001191555n47916563l6294ec9ba34e33e4@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  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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 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


pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Listen / Notify - what to do when the queue is full
Next
From: David Christensen
Date:
Subject: Patch rev 2: MySQL-ism help patch for psql