Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wcCoY-003Aa2-1R for pgsql-bugs@arkaria.postgresql.org; Wed, 24 Jun 2026 01:54:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wcCoX-00Ekys-1A for pgsql-bugs@arkaria.postgresql.org; Wed, 24 Jun 2026 01:54:05 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wcCoX-00Ekyk-0K for pgsql-bugs@lists.postgresql.org; Wed, 24 Jun 2026 01:54:05 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wcCoR-000000021XI-0Lrs; Wed, 24 Jun 2026 01:54:04 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.18.1/8.18.1) with ESMTP id 65O1rtAj990482; Tue, 23 Jun 2026 21:53:55 -0400 From: Tom Lane To: Amit Langote cc: Etsuro Fujita , Matheus Alcantara , Ayush Tiwari , Rafia Sabih , 798604270@qq.com, pgsql-bugs@lists.postgresql.org, Amit Langote Subject: Re: BUG #19484: Segmentation fault triggered by FDW In-reply-to: References: <19484-a3cb82c8cde3c8fa@postgresql.org> Comments: In-reply-to Amit Langote message dated "Wed, 24 Jun 2026 10:43:32 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <990480.1782266035.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Jun 2026 21:53:55 -0400 Message-ID: <990481.1782266035@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Amit Langote writes: > crake is now red on REL_18: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=3Dcrake&dt=3D202= 6-06-24%2000%3A02%3A03 > It reports sizeof(ModifyTableState) grew by 8 bytes. > That=E2=80=99s from adding mt_fdwPrivLists at the end of the struct. Pla= cing it > last keeps existing field offsets stable, which is what extensions readi= ng > the node rely on, but it does grow the struct, which is what the checker > flags. I believe we=E2=80=99ve added trailing struct members in back bra= nches > 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