A few years ago, this list had a brief conversation on $SUBJECT: http://archives.postgresql.org/message-id/1215443493.4051.600.ca...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers