Re: shared memory release following failed lock acquirement.

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: shared memory release following failed lock acquirement.
Дата
Msg-id 6EE64EF3AB31D5448D0007DD34EEB3412A74DB@Herge.rcsinc.local
обсуждение исходный текст
Ответ на shared memory release following failed lock acquirement.  ("Merlin Moncure" <merlin.moncure@rcsonline.com>)
Ответы Re: shared memory release following failed lock acquirement.  ("Simon Riggs" <simon@2ndquadrant.com>)
Список pgsql-hackers
> The name max_locks_per_transaction indicates a limit of some kind. The
> documentation doesn't mention anything about whether that limit is
> enforced
> or not.
>
> I suggest the additional wording:
> "This parameter is not a hard limit: No limit is enforced on the
number of
> locks in each transaction. System-wide, the total number of locks is
> limited
> by the size of the lock table."


I think it's worse than that.  First of all, user locks persist outside
of transactions, but they apply to this limit.  A more appropriate name
for the GUC variable would be 'estimated_lock_table_size_per_backend',
or something like that.  I've been putting some thought into reworking
the userlock contrib module into something acceptable into the main
project, a substantial part of that being documentation changes.

Merlin


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

Предыдущее
От: John DeSoi
Дата:
Сообщение: looking for pgEdit beta testers
Следующее
От: "Merlin Moncure"
Дата:
Сообщение: spurious function execution in prepared statements.