public inbox for [email protected]
help / color / mirror / Atom feedFrom: Noah Misch <[email protected]>
To: Tom Lane <[email protected]>
Cc: Aleksander Alekseev <[email protected]>
Cc: pgsql-hackers <[email protected]>
Cc: Marco Slot <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: Christoph Berg <[email protected]>
Cc: Pavan Deolasee <[email protected]>
Subject: Re: Potential ABI breakage in upcoming minor releases
Date: Fri, 15 Nov 2024 15:07:08 -0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<CAJ7c6TPcUJq_Bwo69f6ysRA1UbmSh_hOOEzJ2EvM0cW=3VEh5w@mail.gmail.com>
<CAFMSG9Hy-2-8tfmmKy7noCbA3Yn1UY2SFUwYj7wHODTO8gDm8w@mail.gmail.com>
<CAJ7c6TMCc85YoiSKex5Sztz6bEmV-0YqL7FY=_MxxcyoMGTDfQ@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
On Fri, Nov 15, 2024 at 05:37:01PM -0500, Tom Lane wrote:
> Noah Misch <[email protected]> writes:
> > Currently, we have Christoph Berg writing "I'd say the ship has sailed, a new
> > release would now break things the other way round." and you writing in favor
> > of undoing. It think it boils down to whether you want N people to recompile
> > twice or M>N people to recompile once, where we don't know N or M except that
> > M > N. Fortunately, the N are probably fairly well represented in this
> > thread. So to all: please speak up by 2024-11-16T17:00+0000 if you think it's
> > the wrong choice to bring back the v16.4 ABI and tell people to rebuild
> > extensions built against v16.5 (likewise for corresponding versions of
> > v14-v17). Currently, the plan of record is to do that.
>
> Well, no, what I propose is for some number of people to not recompile
> extensions at all. Only the sort of early adopters who install a new
> PG release on day one will have run into this, so I anticipate that
> that number will be much larger than the number who have already done
> a rebuild.
If you're saying that undoing the ABI break would allow the M builders to
rebuild zero times, I agree. In other words, here are the number of rebuilds
by builder group:
If we undo, group N: 2 rebuilds
If we undo, group M: 0 rebuilds
If we don't undo, group N: 1 rebuild
If we don't undo, group M: 1 rebuild
I think you're predicting that M is much larger than N. That may be so. A
builder will be in group N if they publish or consume 2024-11-14 builds for
any amount of time. A builder is in group M if they skip the 2024-11-14
release entirely. Note that people getting binaries from someone else don't
increase the size of N or M; builders of binaries (both packagers and
self-packaging users) are the populations to count here.
In this thread, Christoph Berg and Gregory Smith have asserted membership in
that group N. We can indeed advise builders to wait in group M instead of
joining group N, but N is already nonempty. Also, some builders and users of
their builds can't afford to wait. That's why I described it the way I did.
I'm no longer arguing against the undo, but I'm trying to explain the
consequences rigorously.
view thread (26+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Potential ABI breakage in upcoming minor releases
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox