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

From Tom Lane
Subject Re: deadlock_timeout at < PGC_SIGHUP?
Date
Msg-id 12687.1301404838@sss.pgh.pa.us
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
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Mar 29, 2011 at 1:38 AM, Noah Misch <noah@leadboat.com> wrote:
>> What is notable/surprising about the behavior when two backends have different
>> values for deadlock_timeout?

> I'd be inclined to think that PGC_SUSET is plenty.  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?

Yeah, that was my reaction too: what is the use case for letting
different backends have different settings?  It fails to give any real
guarantees about who wins a deadlock, and I can't see any other reason
for wanting session-specific settings.

I don't know how difficult a priority setting would be.  IIRC, the
current deadlock detector always kills the process that detected the
deadlock, but I *think* that's just a random choice and not an essential
feature.  If so, it'd be pretty easy to instead kill the lowest-priority
xact among those involved in the deadlock.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: deadlock_timeout at < PGC_SIGHUP?
Next
From: Tom Lane
Date:
Subject: Re: Replication server timeout patch