Re: Streaming decoding fails with "unexpected table_index_fetch_tuple call during logical decoding" when a relation has a TOASTed conbin (follow-up to BUG #18641)

From: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
To: "'jiri(dot)kavalik(at)comgate(dot)cz'" <jiri(dot)kavalik(at)comgate(dot)cz>
Cc: pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: Streaming decoding fails with "unexpected table_index_fetch_tuple call during logical decoding" when a relation has a TOASTed conbin (follow-up to BUG #18641)
Date: 2026-10-02 07:33:09
Message-ID: OS7PR01MB183170479614BCD8C3E2F8560F5892@OS7PR01MB18317.jpnprd01.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi,

This is the reply for [1]. My mailer could not receive the original post due to
the company's policy, so I will put as the normal post. Sorry for inconvenience.

I confirmed this could happen on PG18, PG17 and PG14. Not tested, but expecting
for PG15 and 166 as well. This could not happen on PG19/HEAD because the
elog(ERROR) was removed by 87f7b824f20, but possible for all branches.

I think your analysis is correct. bsysscan tries to indicate that whether we're
scanning a system table, which was turned on at systable_beginscan* and turned
off at systable_endscan*. But if the systable scan is nested (i.e., pg_constraint.conbin),
the flag can be wrong reset. In PG18- the state is checked for every getnextslot,
which raised the ERROR. In PG19+ the check is unified at the beginning thus the
ERROR does not happen, but I guess the flag can be still wrong.

One idea is to track the depth of scans. Attached patch is for PG18, and I tried not
to modify the header as much as possible. It also had a test code based on your
reproducer. Can you see it's same as your expectation?

[1]: https://www.postgresql.org/message-id/CAF7a2M-OF%2BTjYUBvkSV2oyZNYuPm%3DEqTApcMDOC%2BaevBFPuWrg%40mail.gmail.com

Best regards,
Hayato Kuroda
FUJITSU LIMITED

Attachment Content-Type Size
v1-0001-Track-the-depth-of-scans-of-system-tables.patch application/octet-stream 8.3 KB

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message rahul 2026-10-02 07:47:18 Re: Wrong results: hashed SubPlan referenced twice after OR-qual extraction reuses a stale hash table (13 to 19beta4)
Previous Message rahul 2026-10-02 07:00:13 Re: PostgreSQL 18.6/17.11: standby PANIC on restart after VM truncation