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.
|
Список | 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 по дате отправления: