On Wed, Mar 30, 2011 at 04:48:26PM -0400, Robert Haas wrote:
> On Tue, Mar 29, 2011 at 2:29 PM, Noah Misch <[email protected]> wrote:
> >> 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?
> >
> > The other major use case is reducing latency in deadlock-prone
> > transactions. ?By
> > reducing deadlock_timeout for some or all involved transactions, the error
> > will
> > arrive earlier.
>
> Good point.
>
> >> Is it worth thinking about having an explicit setting for deadlock
> >> priority? ?That'd be more work, of course, and I'm not sure it it's
> >> worth it, but it'd also provide stronger guarantees than you can get
> >> with this proposal.
> >
> > That is a better UI for the first use case. ?I have only twice wished to
> > tweak
> > deadlock_timeout: once for the use case you mention, another time for that
> > second use case. ?Given that, I wouldn't have minded a rough UI. ?If you'd
> > use
> > this often and assign more than two or three distinct priorities, you'd
> > probably
> > appreciate the richer UI. ?Not sure how many shops fall in that group.
>
> Me neither. If making the deadlock timeout PGC_SUSET is independently
> useful, I don't object to doing that first, and then we can wait and
> see if anyone feels motivated to do more.
Here's the patch for that. Not much to it.
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 3981969..f94782f 100644
*** a/doc/src/sgml/config.sgml
--- b/doc/src/sgml/config.sgml
***************
*** 5258,5264 **** 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.
</para>
<para>
--- 5258,5265 ----
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. Only superusers can change
! this setting.
</para>
<para>
diff --git a/src/backend/utils/index 92391ed..48ffe95 100644
*** a/src/backend/utils/misc/guc.c
--- b/src/backend/utils/misc/guc.c
***************
*** 1532,1539 **** static struct config_int ConfigureNamesInt[] =
},
{
! /* This is PGC_SIGHUP so all backends have the same value. */
! {"deadlock_timeout", PGC_SIGHUP, LOCK_MANAGEMENT,
gettext_noop("Sets the time to wait on a lock before
checking for deadlock."),
NULL,
GUC_UNIT_MS
--- 1532,1539 ----
},
{
! /* 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
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
