Re: dynamic shared memory and locks

On Thu, Jan 23, 2014 at 11:10 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Jan 22, 2014 at 12:42 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> On 2014-01-22 12:40:34 -0500, Robert Haas wrote:
>>> On Wed, Jan 22, 2014 at 12:11 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> > Andres Freund <andres(at)2ndquadrant(dot)com> writes:
>>> >> Shouldn't we introduce a typedef LWLock* LWLockid; or something to avoid
>>> >> breaking external code using lwlocks?
>>> >
>>> > +1, in fact there's probably no reason to touch most *internal* code using
>>> > that type name either.
>>>
>>> I thought about this but figured it was too much of a misnomer to
>>> refer to a pointer as an ID. But, if we're sure we want to go that
>>> route, I can go revise the patch along those lines.
>>
>> I personally don't care either way for internal code as long as external
>> code continues to work. There's the argument of making the commit better
>> readable by having less noise and less divergence in the branches and
>> there's your argument of that being less clear.
>
> OK, well then, if no one objects violently, I'll stick my current
> approach of getting rid of all core mentions of LWLockId in favor of
> LWLock *, but also add typedef LWLock *LWLockId with a comment that
> this is to minimize breakage of third-party code.

Hearing no objections, violent or otherwise, I've done that, made the
other adjustments suggested by Andres and KaiGai, and committed this.
Let's see what the buildfarm thinks...

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company