Re: dynamic shared memory and locks

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: dynamic shared memory and locks
Date: 2014-01-23 16:10:44
Message-ID: CA+Tgmoa66=edm6T1CyG809g1RiV04BbeQv92g=jEgKPJidwvJg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

--
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 Florian Pflug 2014-01-23 16:13:16 Passing "direct" args of ordered-set aggs to the transition function
Previous Message Andres Freund 2014-01-23 16:03:33 Re: Add %z support to elog/ereport?