Make deadlock_timeout PGC_SUSET rather than PGC_SIGHUP.

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

1 files changed, 2 insertions, 1 deletions

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 794aef4e6aa..3f6986fc1be 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -5266,7 +5266,8 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
         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>