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.
(Of course, we're speaking of 9.2.)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
