Re: deadlock_timeout at < PGC_SIGHUP? - Mailing list pgsql-hackers

From Noah Misch
Subject Re: deadlock_timeout at < PGC_SIGHUP?
Date
Msg-id 20110329182933.GA10664@tornado.gateway.2wire.net
Whole thread Raw
In response to Re: deadlock_timeout at < PGC_SIGHUP?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: deadlock_timeout at < PGC_SIGHUP?
List pgsql-hackers
On Tue, Mar 29, 2011 at 08:26:44AM -0400, Robert Haas wrote:
> I'd be inclined to think that PGC_SUSET is plenty.

Agreed.  A superuser who would have liked PGC_USERSET can always provide a
SECURITY DEFINER function.

> 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.

> 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.

Thanks,
nm


pgsql-hackers by date:

Previous
From: Christopher Browne
Date:
Subject: Re: Triggers on system catalog
Next
From: Dimitri Fontaine
Date:
Subject: Re: Another swing at JSON