On Wed, Mar 30, 2011 at 04:48:26PM -0400, Robert Haas wrote:
> On Tue, Mar 29, 2011 at 2:29 PM, Noah Misch <noah@leadboat.com> 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.
