Re: deadlock_timeout at < PGC_SIGHUP?
От | Noah Misch |
---|---|
Тема | Re: deadlock_timeout at < PGC_SIGHUP? |
Дата | |
Msg-id | 20110611214314.GC21098@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: deadlock_timeout at < PGC_SIGHUP? (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: deadlock_timeout at < PGC_SIGHUP?
|
Список | pgsql-hackers |
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.
Вложения
В списке pgsql-hackers по дате отправления: