Re: RequestAddinLWLocks(int n)

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RequestAddinLWLocks(int n)
Date: 2015-07-31 17:35:25
Message-ID: CA+TgmoZV-KTikRht7nKXqZjFS=hRgEdGHbwkE9A3Wq68as_b1w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 31, 2015 at 11:56 AM, Jesper Pedersen
<jesper(dot)pedersen(at)redhat(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-07-31 17:40:14 Re: Autonomous Transaction is back
Previous Message Robert Haas 2015-07-31 17:31:54 Re: Re: Using quicksort and a merge step to significantly improve on tuplesort's single run "external sort"