From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring. |
Date: | 2016-02-10 16:36:36 |
Message-ID: | 27480.1455122196@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Feb 10, 2016 at 11:08 AM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>> (Sorry if this was discussed already, I haven't been paying attention)
>>
>> LWLockAssign() is used by extensions. Are we OK with just breaking them,
>> requiring them to change LWLockAssign() with the new mechanism, with #ifdefs
>> to support multiple server versions? Seems like it shouldn't be too hard to
>> keep LWLockAssign() around for the benefit of extensions, so it seems a bit
>> inconsiderate to remove it.
> If there's a strong feeling that we should keep the old APIs around,
> we can do that, but I think that (1) if we don't remove them now, we
> probably never will and (2) they are vile APIs. Allocating the number
> of add-in lwlocks that are requested or a minimum of 3 is just awful.
> If somebody allocates a different number than they request it
> sometimes works, except when combined with some other extension, when
> it maybe doesn't work. This way, you ask for an LWLock under a given
> name and then get it under that name, so if an extension does it
> wrong, it is that extension that breaks rather than some other one. I
> think that's enough benefit to justify requiring a small code change
> on the part of extension authors that use LWLocks, but that's
> obviously biased by my experience maintaining EDB's extensions, and
> other people may well feel differently.
FWIW, I wasn't paying attention either, but I'm convinced by Robert's
argument. Avoiding coupling between extensions is worth an API break.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2016-02-10 17:45:24 | Re: [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring. |
Previous Message | Robert Haas | 2016-02-10 16:21:31 | Re: [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring. |
From | Date | Subject | |
---|---|---|---|
Next Message | Mike Rylander | 2016-02-10 16:45:47 | Re: old bug in full text parser |
Previous Message | Robert Haas | 2016-02-10 16:34:26 | Re: Patch: fix lock contention for HASHHDR.mutex |