Re: deadlock_timeout at < PGC_SIGHUP?

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