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)

Hi,

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