Re: dynamic shared memory and locks - Mailing list pgsql-hackers

From Andres Freund
Subject Re: dynamic shared memory and locks
Date
Msg-id 20140122165133.GA30218@alap3.anarazel.de
Whole thread Raw
In response to Re: dynamic shared memory and locks  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: dynamic shared memory and locks  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2014-01-10 13:11:32 -0500, Robert Haas wrote:
> OK, I've implemented this: here's what I believe to be a complete
> patch, based on the previous lwlock-pointers.patch but now handling
> LOCK_DEBUG and TRACE_LWLOCKS and dtrace and a bunch of other loose
> ends.  I think this should be adequate for allowing lwlocks to be
> stored elsewhere in the main shared memory segment as well as in
> dynamic shared memory segments.
> 
> Thoughts?

Shouldn't we introduce a typedef LWLock* LWLockid; or something to avoid
breaking external code using lwlocks? Requiring code that has worked for
several versions to sprinkle version specific ifdefs seems unneccessary
here.

I see the comments still claim
+ * LWLock is between 16 and 32 bytes on all known platforms, so these two
+ * cases are sufficient.
+ */
+#define LWLOCK_PADDED_SIZE    (sizeof(LWLock) <= 16 ? 16 : 32)

I don't think that's true anymore with the addition of the tranche
id. The new minimum size seems to be 20 on 32bit platforms. That could
be fixed by making the tranche id a uint8, but I don't think that's
necessary, so just removing the support for < 32 seems sufficient.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Hard limit on WAL space used (because PANIC sucks)
Next
From: Tom Lane
Date:
Subject: Re: Patch: Show process IDs of processes holding a lock; show relation and tuple infos of a lock to acquire