Re: deadlock_timeout at < PGC_SIGHUP?

Поиск
Список
Период
Сортировка
От Noah Misch
Тема Re: deadlock_timeout at < PGC_SIGHUP?
Дата
Msg-id 20110329182933.GA10664@tornado.gateway.2wire.net
обсуждение исходный текст
Ответ на Re: deadlock_timeout at < PGC_SIGHUP?  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: deadlock_timeout at < PGC_SIGHUP?  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Tue, Mar 29, 2011 at 08:26:44AM -0400, Robert Haas wrote:
> I'd be inclined to think that PGC_SUSET is plenty.

Agreed.  A superuser who would have liked PGC_USERSET can always provide a
SECURITY DEFINER function.

> 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.

> 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.

Thanks,
nm


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Christopher Browne
Дата:
Сообщение: Re: Triggers on system catalog
Следующее
От: Dimitri Fontaine
Дата:
Сообщение: Re: Another swing at JSON