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) - Mailing list pgsql-bugs

From Zhijie Hou
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
Msg-id CAFvd2n9Ooq4UQ4er2faS5StHXAFz61=paLRYn0g2gvUo7j5S_Q@mail.gmail.com
Whole thread
In response to 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)  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
List pgsql-bugs
Hi,

On Fri, Oct 2, 2026 at 3:33 PM Hayato Kuroda (Fujitsu)
<kuroda.hayato@fujitsu.com> wrote:
>
> 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?

I think using a counter to fix this is OK. But I'm wondering whether it's
necessary to keep both the boolean and the counter, could we merge them into a
single parameter to simplify things?

Best Regards,
Zhijie Hou



pgsql-bugs by date:

Previous
From: Dmitry Dolgov
Date:
Subject: Re: BUG #19735: `jsonb_object_agg_unique_strict` drops a JSONB `null` value as if it were SQL NULL
Next
From: Tom Lane
Date:
Subject: Re: BUG #19747: pg_dump does not pin array_nulls, so restore mangles NULL array elements