Re: deadlock_timeout at < PGC_SIGHUP?
От | Tom Lane |
---|---|
Тема | Re: deadlock_timeout at < PGC_SIGHUP? |
Дата | |
Msg-id | 12687.1301404838@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: deadlock_timeout at < PGC_SIGHUP? (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: deadlock_timeout at < PGC_SIGHUP?
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Tue, Mar 29, 2011 at 1:38 AM, Noah Misch <noah@leadboat.com> wrote: >> What is notable/surprising about the behavior when two backends have different >> values for deadlock_timeout? > I'd be inclined to think that PGC_SUSET is plenty. 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? Yeah, that was my reaction too: what is the use case for letting different backends have different settings? It fails to give any real guarantees about who wins a deadlock, and I can't see any other reason for wanting session-specific settings. I don't know how difficult a priority setting would be. IIRC, the current deadlock detector always kills the process that detected the deadlock, but I *think* that's just a random choice and not an essential feature. If so, it'd be pretty easy to instead kill the lowest-priority xact among those involved in the deadlock. regards, tom lane
В списке pgsql-hackers по дате отправления: