On Fri, Dec 16, 2016 at 12:37 PM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
