On Fri, Dec 16, 2016 at 12:37 PM, Andres Freund <andres@anarazel.de> wrote:
> Yea, I don't think that's good either. I'm all for evolving APIs when
> necessary, but constantly breaking the same API release after release
> seems indicative of needing to spend a bit more time on it in the first
> round.
I am not sure the issue was time so much as the ability to foresee all
the problems we'd want to solve. 9.4 added tranches and converted
everything to LWLock * instead of LWLockId, but I think all of the old
APIs still worked. At that point, we didn't have parallel query and
we weren't that close to having it, so I was loathe to do anything too
invasive. 9.5 removed LWLockAcquireWithVar() and added
LWLockReleaseClearVar(), but most of the API was still fine. 9.6
moved almost everything to tranches and removed RequestAddinLWLocks()
and LWLockAssign(), which was a big break for extensions -- but that
wasn't because of parallel query, but rather because we wanted to use
tranches to support the wait_event stuff and we also wanted to be able
to pad different tranches differently. This latest change is inspired
by the fact that the 9.4-era changes to support parallel query weren't
quite smart enough to be able to cope with the possibility of multiple
tranches with the same tranche ID in a reasonable way. That last one
is indeed an oversight but in January of 2014 it wasn't very clear
that we were going to have tranche-ified every LWLock in the system,
without which this change wouldn't be possible. Quite a lot of work
by at least 3 or 4 different people went into that tranche-ification
effort.
I think it's quite surprising how fast the LWLock system has evolved
over the last few years. When I first started working on PostgreSQL
in 2008, there was no LWLockAcquireOrWait, none of the Var stuff, the
padding was much less sophisticated, no tranches, no atomics, volatile
qualifiers all over the place... and all of that has changed in the
last 5 years. Pretty amazing, actually, IMHO. If our LWLocks improve
as much between now and 2021 as they have between 2011 and now, it'll
be worth almost any amount of API breakage to get there. I don't
personally have any plans or ideas that would involve breaking things
for extensions again any time soon, but I won't be very surprised if
somebody else comes up with one.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company