Re: deadlock_timeout at < PGC_SIGHUP?

From: Noah Misch <noah(at)leadboat(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: deadlock_timeout at < PGC_SIGHUP?
Date: 2011-03-29 18:29:33
Message-ID: 20110329182933.GA10664@tornado.gateway.2wire.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2011-03-29 18:42:41 Re: Another swing at JSON
Previous Message Christopher Browne 2011-03-29 18:17:36 Re: Triggers on system catalog