Skip site navigation (1) Skip section navigation (2)

Re: deadlock_timeout at < PGC_SIGHUP?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: deadlock_timeout at < PGC_SIGHUP?
Date: 2011-03-30 20:48:26
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
On Tue, Mar 29, 2011 at 2:29 PM, Noah Misch <noah(at)leadboat(dot)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.

(Of course, we're speaking of 9.2.)

Robert Haas
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Jeff DavisDate: 2011-03-30 20:58:33
Subject: Re: Problem with pg_upgrade?
Previous:From: Robert HaasDate: 2011-03-30 20:46:00
Subject: Re: Problem with pg_upgrade?

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group