On Sat, Oct 17, 2026 at 12:57 AM Matheus Alcantara <[email protected]> wrote: > On Fri Oct 16, 2026 at 9:10 AM -03, Etsuro Fujita wrote: > >> 2: stale ForeignScanHash entries after a failed portal
> > I couldn't reproduce this in my environment. Could you provide the > > reproducer in more detail including the foreign table definition, the > > postgres_fdw options, ...? > create extension postgres_fdw; > create server loopback foreign data wrapper postgres_fdw options (dbname > 'postgres', port '5432'); > create user mapping for current_user server loopback; > create table t (a int); > insert into t values (1), (2), (3), (4); > create foreign table ft (a int) server loopback options (table_name 't'); > > begin; > declare c cursor for select 1 / (a - 3) from ft order by a; > fetch 1 from c; > savepoint s2; > fetch 5 from c; > rollback to s2; > commit; > > After the COMMIT command it produces: > > WARNING: 01000: ForeignScan node 0x106019368 still existing > LOCATION: AtEOXact_ForeignScan, postgres_fdw.c:4381 > > The details that matter are that the first "fetch 1" happens before the > savepoint, so IIUC the scan and its cursor belong to the outer level, > and that the error happens while fetching inside the savepoint. The > expression 1 / (a - 3) is not pushed down, so the division by zero is > raised locally while the scan returns rows, and the portal is left in > the failed state. If I add this after "rollback to s2" and before > "commit": > > close c; > savepoint s3; > select 1; > release s3; > > the backend crashes in the subtransaction callback. Thanks for the detailed information! I could reproduce this. I was testing using the wrong patch, sorry. > > Thanks for working on the fix! It would be great if you share it. > I'm attaching the v4 patch. It is your v3-0001 plus the fixes from my > previous email that you agree. Since you said you'd remove the > restrictions of 3 and 4, and add the comments of 6, I went ahead and did > them in this version. Thanks for the patch! Will review. I think the patch is master-only, because 1) there is no field report about the series of open-cursor issues while they exist since the introduction of postgres_fdw, and 2) the patch is large/invasive, so I will return to this somewhere in the v20 development cycle after working on some other stuff. Best regards, Etsuro Fujita
