Re: pg_locks needs a facelift

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_locks needs a facelift
Дата
Msg-id 4812.1115088181@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_locks needs a facelift  ("Merlin Moncure" <merlin.moncure@rcsonline.com>)
Список pgsql-hackers
"Merlin Moncure" <merlin.moncure@rcsonline.com> writes:
> Yep.  Actually, the biggest part of this was figuring out what to do
> about the pg_locks view.  Since that's basically decided, all that
> remains is to decide what if anything to do about the
> max_locks_per_transaction GUC variable.  User locks at the very least
> are extra-transactional so this could perhaps be renamed.

I'm not in favor of renaming the variable unless a really significantly
more descriptive name is proposed.  I can't think of any short names
that are markedly better than max_locks_per_transaction.  To me the
main shortcoming of that name has nothing to do with user locks: it's
that it suggests that we enforce a hard limit on each transaction
individually, when in fact we do no such thing (the limit is on the
total number of locks in existence, not how many are owned by whom).

> FWIW, I'm a huge fan of the current behavior which is to drop
> transactions when running out of lock-space.

I can't quite tell if that was supposed to have a smiley or not ...
        regards, tom lane


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

Предыдущее
От: Neil Conway
Дата:
Сообщение: Re: SPI bug.
Следующее
От: Neil Conway
Дата:
Сообщение: Re: [pgsql-advocacy] Increased company involvement