Re: Potential ABI breakage in upcoming minor releases

From: Noah Misch <noah(at)leadboat(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Aleksander Alekseev <aleksander(at)timescale(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Marco Slot <marco(dot)slot(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Christoph Berg <myon(at)debian(dot)org>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
Subject: Re: Potential ABI breakage in upcoming minor releases
Date: 2024-11-15 23:07:08
Message-ID: 20241115230708.6b.nmisch@google.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 15, 2024 at 05:37:01PM -0500, Tom Lane wrote:
> Noah Misch <noah(at)leadboat(dot)com> 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jonathan S. Katz 2024-11-15 23:28:42 IMPORTANT: Out-of-cycle release scheduled for November 21, 2024
Previous Message Masahiko Sawada 2024-11-15 22:44:04 Re: Parallel heap vacuum