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 1vjg2D-002QZp-2b for pgsql-bugs@arkaria.postgresql.org; Sat, 24 Jan 2026 15:58:50 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vjg2B-0031xr-1N for pgsql-bugs@arkaria.postgresql.org; Sat, 24 Jan 2026 15:58:47 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vjg2B-0031xj-0W for pgsql-bugs@lists.postgresql.org; Sat, 24 Jan 2026 15:58:47 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vjg28-0025w7-2u for pgsql-bugs@lists.postgresql.org; Sat, 24 Jan 2026 15:58:46 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 60OFweAi3256999; Sat, 24 Jan 2026 10:58:40 -0500 From: Tom Lane To: Dean Rasheed cc: dwwoelfel@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #19380: Transition table in AFTER INSERT trigger misses rows from MERGE when used with INSERT in a CTE In-reply-to: References: <19380-4e293be2b4007248@postgresql.org> <1576968.1768929680@sss.pgh.pa.us> <1698130.1768932056@sss.pgh.pa.us> Comments: In-reply-to Dean Rasheed message dated "Sat, 24 Jan 2026 11:48:41 +0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3256997.1769270320.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Sat, 24 Jan 2026 10:58:40 -0500 Message-ID: <3256998.1769270320@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Dean Rasheed writes: > I've pushed this now. Expecting to have to push updates to > .abi-compliance-history soon. crake has reported in [1]: Leaf changes summary: 2 artifacts changed Changed leaf types summary: 2 leaf types changed Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 0 Added fun= ction (2 filtered out) Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added var= iable 'struct AfterTriggersTableData' changed: type size changed from 80 to 64 (in bytes) 2 data member deletions: 'Tuplestorestate* old_del_tuplestore', at offset 56 (in bytes) 'Tuplestorestate* new_ins_tuplestore', at offset 64 (in bytes) there are data member changes: 'TupleTableSlot* storeslot' offset changed from 72 to 56 (in bytes) (b= y -16 bytes) 'struct TransitionCaptureState' changed: type size changed from 24 to 40 (in bytes) 2 data member insertions: 'AfterTriggersTableData* tcs_update_private', at offset 24 (in bytes) 'AfterTriggersTableData* tcs_delete_private', at offset 32 (in bytes) there are data member changes: name of 'TransitionCaptureState::tcs_private' changed to 'TransitionCa= ptureState::tcs_insert_private' I find it unhelpful that it reported the AfterTriggersTableData change as an ABI change, even though that struct is not globally accessible. I wonder if there's some libabigail switches we should be tweaking to refine that. regards, tom lane [1] https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=3Dcrake&= dt=3D2026-01-24%2013%3A06%3A41&stg=3Dabi-compliance-check