From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, 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-13 14:54:07 |
Message-ID: | 20163.1455375247@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> On 10 February 2016 at 16:36, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-02-13 15:16:14 | Re: Re: [COMMITTERS] pgsql: Add some isolation tests for deadlock detection and resolution. |
Previous Message | Greg Stark | 2016-02-13 13:41:29 | Re: [COMMITTERS] pgsql: Add some isolation tests for deadlock detection and resolution. |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-02-13 15:10:29 | Re: Crash with old Windows on new CPU |
Previous Message | Fabien COELHO | 2016-02-13 14:41:08 | Re: extend pgbench expressions with functions |