Subject: Re: BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded

From: Kyotaro Horiguchi <[email-masked]>
Date: Thu, 22 Feb 2024 16:00:27 +0900 (JST)

At Thu, 22 Feb 2024 14:38:15 +0900 (JST), Kyotaro Horiguchi <[email-masked]> wrote in 
> At Thu, 22 Feb 2024 11:49:29 +0800, Tender Wang <[email-masked]> wrote in 
> > Changing the behavior of tuplestore can work for this issue,  but I'm not
> > sure if this change will affect other components which depend on
> > BufFile(like nodeMaterial)

In the case of nodeMaterial, tuplestore is simply discarded and
underlying files are removed without flushing by the resource owner
mechanism. On the other hand, in the case of this bug report, the
files in the problem tuplestore are not managed by a resource
owner. As a result, PortalDrop have to explicitly call tuplestore_end
to release resources used by the tuplestore.

> 	/*
> 	 * Delete tuplestore if present.  We should do this even under error
> 	 * conditions; since the tuplestore would have been using cross-
> 	 * transaction storage, its temp files need to be explicitly deleted.
> 	 */
> 	if (portal->holdStore)
> 	{
> 		MemoryContext oldcontext;
> 
> 		oldcontext = MemoryContextSwitchTo(portal->holdContext);
> 		tuplestore_end(portal->holdStore);

As far as I can see, there are no caller sites to tuplestore_end in
the abort path or any error handling path.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

---

From: Alex Masterov <[email-masked]>
Date: Wed, 6 May 2026 13:26:51 +0200

Hi,

 While running tests with Neon, we discovered an assertion failure that can
 occur during re-entrant AbortTransaction() calls.

 The issue arises when an error occurs during AbortTransaction() after
 ProcArrayEndTransaction() has cleared MyProc->xid. If another error is
raised
 during cleanup (e.g., in AtEOXact_Inval()), the PostgresMain error handler
 invokes AbortCurrentTransaction() again. The second AbortTransaction() call
 reads a still-valid s->transactionId (CleanupTransaction() hasn't run yet)
 and passes it to ProcArrayEndTransaction(), which then hits:

   Assert(TransactionIdIsValid(proc->xid))

 because MyProc->xid was already cleared by the first call.

 The attached patch fixes this by checking MyProc->xid validity before
calling
 RecordTransactionAbort() and only passing a valid latestXid when
appropriate.

 **Reproduction:**
 This can be reproduced reliably using the injection_points extension:

 1. Attach the injection point:
   SELECT injection_points_attach('transaction-end-process-inval', 'error');
 2. Create invalidation messages: CREATE TABLE test(id int);
 3. Trigger abort: ROLLBACK;

 Without the fix: assertion crash on ProcArrayEndTransaction()
 With the fix applied: the script will panic with "ERRORDATA_STACK_SIZE
exceeded"
 due to re-entrant error handling, demonstrating that the assertion is
resolved.

 I've included a reproduction script and the fix that clearly shows both
behaviors.

 **Files attached:**
 - 0001-xact-Prevent-assertion-failure-in-re-entrant-Abort.patch
 - repro_minimal_panic_if_fixed.sh

 Thoughts?

 Best regards,
 Alexey