On 07/31/2015 01:35 PM, Robert Haas wrote:
On Fri, Jul 31, 2015 at 11:56 AM, Jesper Pedersen
<jesper.peder...@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.
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
*** /tmp/8hB0Ty_xfunc.sgml 2015-07-31 14:05:45.331691017 -0400
--- doc/src/sgml/xfunc.sgml 2015-07-31 14:05:29.710696535 -0400
***************
*** 3339,3344 ****
--- 3339,3351 ----
</programlisting>
from <function>_PG_init</>.
</para>
+ <note>
+ <para>
+ By default a minimum of 4 LWLocks are requested in order to maintain
+ backwards-compatibility, which may lead to debugging issues if the extensions
+ doesn't request the correct number of LWLocks needed.
+ </para>
+ </note>
<para>
To avoid possible race-conditions, each backend should use the LWLock
<function>AddinShmemInitLock</> when connecting to and initializing
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
