Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Oct 20, 2025 at 3:34 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> BTW, not critical right now, but thought I'd mention it: ISTM
>> this mechanism obviates the need for the single-purpose NodeTag ABI
>> checks installed by commit eea9fa9b2.
> Hmm, but: the code in gen_node_support.pl would tell you about trouble
> before you committed, whereas the ABI checks would only tell you about
> trouble after you commit. It seems to me that we are in desperate need
> of reducing, rather than increasing, the number of mistakes you can
> make and find out about only after commit.
There are enough other ways to break ABI that I don't think catching
just this one before commit will move the needle for anyone. Instead,
the mistake I'm hoping to eliminate here is forgetting to arm the
NodeTag ABI check, or doing it wrong.
I do take your point that being able to find things before commit
is helpful. But I think the answer to that is to get this
general-purpose ABI check mechanism sufficiently well product-ized
that committers can run it locally if they choose. Ideally we'd
have multiple BF animals running it, so there's definitely motivation
to get it at least to the point where it doesn't require hand-feeding
by BF owners. (If memory serves, we've had ABI breaks that affected
only 32 bit or only 64 bit machines, and of course there's the
possibility of ones that only manifest with particular feature
selections. So I'm not content with just one animal running it.)
regards, tom lane
