Re: BUG #19484: Segmentation fault triggered by FDW

Amit Langote <amitlangote09(at)gmail(dot)com> writes:
> crake is now red on REL_18:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2026-06-24%2000%3A02%3A03

> It reports sizeof(ModifyTableState) grew by 8 bytes.

> That’s from adding mt_fdwPrivLists at the end of the struct. Placing it
> last keeps existing field offsets stable, which is what extensions reading
> the node rely on, but it does grow the struct, which is what the checker
> flags. I believe we’ve added trailing struct members in back branches
> before for exactly this reason. Is a flagged sizeof increase acceptable
> here under that precedent, or do we now want to avoid any flagged ABI
> change on a back branch?

I don't believe that the addition of ABI checking was meant to change
our back-patching policies, just to make sure we don't make
unintentional ABI changes. As you say, we've added trailing fields
before. The critical question is whether it's likely that any
extensions create their own ModifyTableState nodes (and might make
them too small and/or fail to fill the new field correctly).

I was about to say that that seems unlikely to me, but a check of
Debian Code Search immediately found pg_rewrite doing it. So yeah,
looks like we'd better adopt the no-ABI-break solution.

regards, tom lane