Re: deadlock_timeout at < PGC_SIGHUP?

Noah Misch <noah@leadboat.com>

From: Noah Misch <noah@leadboat.com>
To: pgsql-hackers@postgresql.org
Cc: Robert Haas <robertmhaas@gmail.com>
Date: 2011-06-11T21:43:14Z
Lists: pgsql-hackers

Attachments

On Wed, Mar 30, 2011 at 04:48:26PM -0400, Robert Haas wrote:
> On Tue, Mar 29, 2011 at 2:29 PM, Noah Misch <noah@leadboat.com> wrote:
> >> It's actually not
> >> clear to me what the user could usefully do other than trying to
> >> preserve his transaction by setting a high deadlock_timeout - what is
> >> the use case, other than that?
> >
> > The other major use case is reducing latency in deadlock-prone transactions. ?By
> > reducing deadlock_timeout for some or all involved transactions, the error will
> > arrive earlier.
> 
> Good point.
> 
> >> Is it worth thinking about having an explicit setting for deadlock
> >> priority? ?That'd be more work, of course, and I'm not sure it it's
> >> worth it, but it'd also provide stronger guarantees than you can get
> >> with this proposal.
> >
> > That is a better UI for the first use case. ?I have only twice wished to tweak
> > deadlock_timeout: once for the use case you mention, another time for that
> > second use case. ?Given that, I wouldn't have minded a rough UI. ?If you'd use
> > this often and assign more than two or three distinct priorities, you'd probably
> > appreciate the richer UI. ?Not sure how many shops fall in that group.
> 
> Me neither.  If making the deadlock timeout PGC_SUSET is independently
> useful, I don't object to doing that first, and then we can wait and
> see if anyone feels motivated to do more.

Here's the patch for that.  Not much to it.