On Tue, Sep 15, 2026 at 9:30 AM Rafia Sabih <[email protected]> wrote: > The patches required a minor rebase. > The latest patches attached.
If you enter drain_active_scan() with tuplestore_lost_rows = true, the function will set it to false, which is wrong. I think that drain_active_scan() should store the previous value of tuplestore_lost_rows into a local variable just before setting tuplestore_lost_rows = true, and restore that value in the places where it previously stores false. http://postgr.es/m/CA+Tgmoa-FXH9jZaxm039eWf8=nhnoBfDS=oekfm50sbgeaz...@mail.gmail.com pointed out that pgfdw_subxact_callback() needs to drain active scans before calling RELEASE SAVEPOINT. It still doesn't. You should probably add some transaction-control tests to the regression test suite for postgres_fdw, so that these kinds of issues can't come back once fixed. drain_active_scan() switches to active_fsstate->batch_cxt while it's executing, which causes allocations to be performed in the correct memory context. But that only handles memory allocation, and tuplestores also use files, which are controlled by the resource owner mechanism, not the memory context mechanism. Any files created here should end up owned by whatever the correct resource owner is for the scan we're draining, but instead they end up using the resource owner that's in effect at the time we need to perform the drain. You'll need to save the resource owner and temporarily switch to it here as you do for the memory context. I attach Claude-written test cases for all three issues. -- Robert Haas Databricks
streaming_fetch_lost_rows.sql
Description: Binary data
streaming_fetch_release.sql
Description: Binary data
streaming_fetch_resowner.sql
Description: Binary data
