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: AANLkTinwB74jN-Hw46p8Bx3sjxzVKM6ZRCdoXcXnLQN8@mail.gmail.com (view raw or flat)
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
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

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-2014 The PostgreSQL Global Development Group