On Tue, Mar 29, 2011 at 2:29 PM, Noah Misch <n...@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. (Of course, we're speaking of 9.2.) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
