Re: RequestAddinLWLocks(int n)

On 07/31/2015 01:35 PM, Robert Haas wrote:
> 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.
>

I agree that tagging the requirements for each extension would be ideal
for this.

However, it would probably require to spread out the LWLock allocation
logic as the comment in NumLWLocks describes in order to keep track of
whom is requesting. And also, it would require that extensions upgrade
to the new SPI. The current SPI will have to be kept for a while, and
deprecated for sure.

I don't know if the real life problem is big enough to justify such a
change, but I can take a closer look.

Hence, just the fail eagerly patch first, which may break extensions out
there. Hint about this scenario in xfunc.sgml attached, which may be enough.

Best regards,
Jesper