Re: [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring.
Date
Msg-id 20163.1455375247@sss.pgh.pa.us
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring.  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring.
List pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:
> On 10 February 2016 at 16:36, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> FWIW, I wasn't paying attention either, but I'm convinced by Robert's
>> argument.  Avoiding coupling between extensions is worth an API break.

> Old APIs - why can't we keep it?

Because with the old API, a bug in extension A may go unnoticed in A's
testing but break when it's combined with extension B.  That causes
headaches all around, not just to the extension authors but to their
users.  The new API ensures detection of didn't-request-enough-locks
bugs regardless of which other extensions are installed.  That is worth
the cost of a forced API update, in Robert's judgement and mine too.

(Having said that, I wonder if we could put back the old API as a shim
layer *without* the allocate-some-excess-locks proviso.  That would
get us to a situation where standalone testing of a broken extension
would disclose its bug, without breaking non-buggy extensions.)
        regards, tom lane



pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: extend pgbench expressions with functions
Next
From: Tom Lane
Date:
Subject: Re: Crash with old Windows on new CPU