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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2011-03-30 20:58:33 | Re: Problem with pg_upgrade? |
Previous Message | Robert Haas | 2011-03-30 20:46:00 | Re: Problem with pg_upgrade? |