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