Re: RequestAddinLWLocks(int n)

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: RequestAddinLWLocks(int n)
Дата
Msg-id CA+TgmoZV-KTikRht7nKXqZjFS=hRgEdGHbwkE9A3Wq68as_b1w@mail.gmail.com
обсуждение исходный текст
Ответ на RequestAddinLWLocks(int n)  (Jesper Pedersen <jesper.pedersen@redhat.com>)
Ответы Re: RequestAddinLWLocks(int n)  (Jesper Pedersen <jesper.pedersen@redhat.com>)
Список pgsql-hackers
On Fri, Jul 31, 2015 at 11:56 AM, Jesper Pedersen
<jesper.pedersen@redhat.com> wrote:
> Currently
>
>   Max(lock_addin_request, NUM_USER_DEFINED_LWLOCKS);
>
> LWLock's are added during startup for extensions.
>
> However, this presents a problem if an extension doesn't specify the correct
> number of LWLock's needed, if the total number is <= 4.
>
> The attached patch requires extensions to specify the correct number of
> LWLock's needed. This change will break extensions that specifies an
> incorrect number, but makes it easier to debug which extension which is at
> fault.
>
> Probably too big a change though. Maybe a patch against xfunc.sgml is better
> ?

What I'd actually like to do is make it so that you do
RequestAddinLWLocks(int, char *), requesting a given number of locks
with some particular "tag" string, and then LWLockAssign(char *),
allocating those locks.  Then, if the number allocated doesn't match
the number requested, the server can spit up and die, logging the tag
string on the way down.  Right now, if you've got multiple extensions
loaded that use this interface, it's really hard to debug which one is
to blame if there are problems.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Re: Using quicksort and a merge step to significantly improve on tuplesort's single run "external sort"
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Autonomous Transaction is back