This allows deadlock_timeout to be reduced for transactions that are
particularly likely to be involved in a deadlock, thus detecting it
more quickly. It is also potentially useful as a poor-man's deadlock
priority mechanism: a transaction with a high deadlock_timeout is less
likely to be chosen as the victim than one with a low
deadlock_timeout. Since that could be used to game the system, we
make this PGC_SUSET rather than PGC_USERSET.
At some point, it might be worth thinking about a more explicit
priority mechanism, since using this is far from fool-proof. But
let's see whether there's enough use case to justify the additional
work before we go down that route.
Noah Misch, reviewed by Shigeru Hanada
practice. On a heavily loaded server you might want to raise it.
Ideally the setting should exceed your typical transaction time,
so as to improve the odds that a lock will be released before
- the waiter decides to check for deadlock.
+ the waiter decides to check for deadlock. Only superusers can change
+ this setting.
</para>
<para>
},
{
- /* This is PGC_SIGHUP so all backends have the same value. */
- {"deadlock_timeout", PGC_SIGHUP, LOCK_MANAGEMENT,
+ /* This is PGC_SUSET to prevent hiding from log_lock_waits. */
+ {"deadlock_timeout", PGC_SUSET, LOCK_MANAGEMENT,
gettext_noop("Sets the time to wait on a lock before checking for deadlock."),
NULL,
GUC_UNIT_MS