Hi,
On 2024-06-03 15:21:04 -0400, David E. Wheeler wrote:
> > Extensions in general can do lots of stuff, guaranteeing that bug fixes don't
> > cause any problems is just not feasible.
> >
> > It'd be interesting to see a few examples of actual minor-version-upgrade
> > extension breakages, so we can judge what caused them.
>
> In the community Slack[4], Matthias van de Meent writes[5]:
>
> > Citus’ pg_version_compat.h[7] where it re-implements a low-level function that was newly introduced in PG14.7. If
youbuild against PG14.7+ headers, you may get random crashes when running on 14.6.
I don't see how this would trigger random crashes.
Unfortunately [4] doesn't seem to take me to a relevant message (pruned chat
history?), so I can't infer more from that context.
> I suppose it would work fine on 14.7 if compiled on 14.6 though. I suspect
> there aren’t many examples, though, mostly just a lot of anxiety, and some
> have decided that extensions must be recompiled for every minor release in
> order to avoid the issue. StackGres[7] is one example, but I suspect Omni
> (Yurii’s company) may follow.
Regardless of ABI issues, it's probably a good idea to continually run tests
against in-development minor versions, just to prevent something breaking from
creeping in. IIRC there were a handful of cases where we accidentally broke
some extension, because they relied on some implementation details.
> >> Unless, that is, we can provide a complete list of things not to do (like
> >> make use of padding) to avoid it. Is that feasible?
> >
> > You can't really rely on the contents of padding, in general. So I don't think
> > this is really something that needs to be called out.
>
> Sure, probably not a problem, but if that’s the sole qualifier for making
> binary changes, I think it’s worth saying, as opposed to “we don’t make
> any”. Something like “Only changes to padding, which you never used anyway,
> right?” :-)
IDK, to me something like this seems to promise more than we actually can.
Greetings,
Andres Freund
