RE: [BUG] Assert failure in ReorderBufferReturnTXN during logical decoding due to leaked specinsert change

From: Vishal Prasanna <vishal(dot)g(at)zohocorp(dot)com>
To: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
Cc: "'Álvaro Herrera'" <alvherre(at)kurilemu(dot)de>, "pgsql-bugs" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: RE: [BUG] Assert failure in ReorderBufferReturnTXN during logical decoding due to leaked specinsert change
Date: 2026-03-08 21:14:03
Message-ID: 19ccf4ccdb3.2e31ab735232.2694179375476897261@zohocorp.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi Hayato,

>> Found a workload that can reproduce the issue across all supported versions, except PG 14.
>>
>> For PG 14, since row_filter is not supported, so we can go with the 'publication does not exist' error instead.
>> Refer: PG14-Test-specinsert-cleanup-in-ReorderBufferProcessTXN-error-path.patch
>>
>> For PG 15 - 18, using the row_filter option we can cause an error in the logical decoder.
>
> Per my understanding, for PG16-, the provided workload cannot cause an assertion
> failure because it misses the Assert() in the ReorderBufferReturnTXN(), right?
> Adding the line is essential, otherwise the test could pass even without the fix.

Right. Added `Assert(txn->size == 0)` in `ReorderBufferReturnTXN()` for PG14, 15, 16 patches.

> 01.
> I think it is better to combine tests actual code patches into one. Because they
> would be done when patches are committed.

combined the fix and test into a single patch. since some changes are version specific
(like add assert check for PG14-16, different function names from PG17 -> 18, test case)
separate patches are provided per version. PG15 and PG16 share the same patch.

> 02.
> This issue can happen even on HEAD, but PG18-Fix-specinsert... cannot be applied
> atop the branch. Can you create it as well?

created a separate patch for master.

> 03. 100_bugs.pl
>
> Other tests start from the comment like "The bug...", but it does not follow.
> Can we update?
>
> 04. 100_bugs.pl
>
> Can we just rotate a log instead of starting new instance? It might be faster.
>
> 05. 100_bugs.pl for PG
>
> ```
> # The publication row filter WHERE ((a / 0) > 0) will trigger a division by zero error.
> ```
>
> I think the comment can be improved like:
>
> Create a publication with the zero-division row filter. It always throws an
> ERROR before publishing changes, when the filter is evaluated.
>
> Please see attached my top-up patch for PG18, it addresses comments 03-05.

Applied your suggestions across all versions. Thanks.

Overall:
PG14: Assert check + fix + test (uses 'pub does not exist' error)
PG15-16: Assert check + fix + test (uses row_filter error)
PG17: fix + test (uses row_filter error)
PG18, master: fix + test (uses row_filter error)

Regards,
Vishal Prasanna
Zoho Corporation

Attachment Content-Type Size
master-Fix-specinsert-leak-in-ReorderBufferProcessTXN-error-path.patch application/octet-stream 4.2 KB
PG14-Fix-specinsert-leak-in-ReorderBufferProcessTXN-error-path.patch application/octet-stream 4.3 KB
PG15-16-Fix-specinsert-leak-in-ReorderBufferProcessTXN-error-path.patch application/octet-stream 4.5 KB
PG17-Fix-specinsert-leak-in-ReorderBufferProcessTXN-error-path.patch application/octet-stream 4.3 KB
PG18-Fix-specinsert-leak-in-ReorderBufferProcessTXN-error-path.patch application/octet-stream 4.3 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Hayato Kuroda (Fujitsu) 2026-03-09 04:52:56 RE: [BUG] Assert failure in ReorderBufferReturnTXN during logical decoding due to leaked specinsert change
Previous Message Laurenz Albe 2026-03-08 17:58:30 Re: BUG #19426: pgdump is stuck