public inbox for [email protected]  

help / color / mirror / Atom feed

From: Hayato Kuroda (Fujitsu) <[email protected]>
To: 'Vishal Prasanna' <[email protected]>
Cc: pgsql-bugs <[email protected]>
Subject: RE: [BUG] Assert failure in ReorderBufferReturnTXN during logical decoding due to leaked specinsert change
Date: Mon, 23 Feb 2026 08:26:14 +0000
Message-ID: <OS9PR01MB121492243C9366FBDF8334947F577A@OS9PR01MB12149.jpnprd01.prod.outlook.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>

Dear Vishal,

Thanks for reporting the issue.

Your analysis looks correct. ReorderBufferProcessTXN() rarely fails, thus the
issue may be missed. Looks like the code path you pointed out exists from the
beginning, but I found your workload could reproduce only on PG17.

Regarding the PG16 and earlier versions, the problematic Assert() in
ReorderBufferReturnTXN() does not exist. The commit dbed2e3 added it, and
it was backpatched till PG17. We deallocate ReorderBufferTXN even if the size
is not zero for such versions.

Regarding PG18 and master, the provided workload did not cause an ERROR.
7c99dc5 changed the behavior to report a WARNING instead.

Anyway, I agreed that the leak could happen across all versions.
How about fixing the issue as shown below? Thought?

1. Add an Assert() for PG16-.
2. Make sure specinsert is released for all supported versions.
3. Consider a workload that could reproduce on PG18 and master.
 3-1. If found, the test code can be added for all versions.
 3-2. Otherwise, the test code can be added for PG17-.

> Additional Suggestion:
> Currently in `PG_CATCH` block, `specinsert` is only freed in the `ERRCODE_TRANSACTION_ROLLBACK` branch
> for streaming or prepared transactions, via `ReorderBufferResetTXN()` at line 2691.
> Would it make sense to move the freeing of `specinsert` before the if/else branch,
> so that it is always freed regardless of the error path? This would avoid duplication and ensure
> that `specinsert` is always cleaned up.

It looks OK for me. In this case an argument should be reduced from
ReorderBufferResetTXN(), right? It is harmless because the function is static one.

Best regards,
Hayato Kuroda
FUJITSU LIMITED

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: RE: [BUG] Assert failure in ReorderBufferReturnTXN during logical decoding due to leaked specinsert change
  In-Reply-To: <OS9PR01MB121492243C9366FBDF8334947F577A@OS9PR01MB12149.jpnprd01.prod.outlook.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox