Skip site navigation (1) Skip section navigation (2)

deadlock_timeout at < PGC_SIGHUP?

From: Noah Misch <noah(at)leadboat(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: deadlock_timeout at < PGC_SIGHUP?
Date: 2011-03-29 05:38:38
Message-ID: 20110329053838.GA5499@tornado.leadboat.com (view raw or flat)
Thread:
Lists: pgsql-hackers
A few years ago, this list had a brief conversation on $SUBJECT:
http://archives.postgresql.org/message-id/1215443493.4051.600.camel@ebony.site

What is notable/surprising about the behavior when two backends have different
values for deadlock_timeout?  After sleeping to acquire a lock, each backend
will scan for deadlocks every time its own deadlock_timeout elapses.  Some might
be surprised that a larger-deadlock_timeout backend can still be the one to give
up; consider this timeline:

Backend	Time	Command
A	N/A	SET deadlock_timeout = 1000
B	N/A	SET deadlock_timeout = 100
A	0	LOCK t
B	50	LOCK u
A	100	LOCK u
B	1050	LOCK t
(Backend A gets an ERROR at time 1100)

More generally, one cannot choose deadlock_timeout values for two sessions such
that a specific session will _always_ get the ERROR.  However, one can drive the
probability rather high.  Compare to our current lack of control.

Is some other behavior that only arises when backends have different
deadlock_timeout settings more surprising than that one?

If we could relax deadlock_timeout to a GucContext below PGC_SIGHUP, it would
probably need to stop at PGC_SUSET for now.  Otherwise, an unprivileged user
could increase deadlock_timeout to hide his lock waits from log_lock_waits.  One
could remove that limitation by introducing a separate log_lock_waits timeout,
but that patch would be significantly meatier.  Some might also object to
PGC_USERSET on the basis that a user could unfairly preserve his transaction by
setting a high deadlock_timeout.  However, that user could accomplish a similar
denial of service by idly holding locks or trying deadlock-prone lock
acquisitions in subtransactions.

nm

Responses

pgsql-hackers by date

Next:From: Martijn van OosterhoutDate: 2011-03-29 06:35:10
Subject: Re: Open issues for collations
Previous:From: Fujii MasaoDate: 2011-03-29 04:55:58
Subject: Re: Replication server timeout patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group