On Fri, Oct 2, 2026 at 2:32 AM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
> On Fri, Oct 2, 2026 at 1:47 AM Nikolay Samokhvalov <nik@postgres.ai> wrote:
> > My AI harness for testing reproduced this on
> > REL_19_STABLE at 9e73b209 with Etsuro's v1 patch and prepared the
> > attached incremental patch. It declares the remote cursor before
> > advancing the remote savepoint level, then synchronizes the transaction
> > mode before FETCH. The second FETCH fails with 34000 on v1 and succeeds
> > with this patch.
>
> Will look into the patch.
I think the patch assumes that create_cursor() is called at the same
transaction nesting depth as the local cursor, but that doesn't always
hold; for eg, the case I showed yesterday, that doesn't hold, so it
still fails. So it's a partial solution as proposed. Rather than
complicating the code, I'd like to propose to fix this by just
disallowing first fetching of a cursor within a deeper subtransaction
than it was created in. Here is an updated version for that. This is
an existing issue, so I split it into two:
* v2-0001-Fix-open-cursor-handling.patch
This addresses the existing issue by disallowing the fetching (and the
issue #1 reported by Fujii-san as a side effect).
* v2-0002-Fix-xact-prop-issues.patch
This addresses the remaining issues #2, #3 and #5 reported by
Fujii-san (#4 is not a bug). I will add test cases next.
Best regards,
Etsuro Fujita
