At 2026-07-15 11:50:32，"Rafia Sabih" <[email protected]> wrote > Hello Yilin, > Thanks for your input. But unfortunately I am not able to reproduce the > issue with this test case. Also, I am not able to understand it much, as to > how we are going to access bug2_pid from session 2, because it is a temp > table from a different session. Maybe you can simplify this a little more, > or maybe share the backtrace in case of the crash.
> Yes you are right, this was the gap, in case of crash while draining, > active_fsstate couldn't be cleared and a dangling pointer was left, which > causes the crash on the next execution. > To fix this, I have now added a condition in pgfdw_abort_cleanup, to reset > the active_scan in case of unfinished drain. Since I was not able to use > your test case so I couldn't verify if this fixes the issue. > Apart from that I have now changed the save_to_tuplestore function to only > have active_fsstate and PGconn. Also, there is a wrapper function to call > it and check the relevant condition so we don't duplicate it all those 5 > places. I have also added the calls to function to drain tuples to > tuplestore in execute_dml_stmt and exectute_foreign_modify, to ensure that > whenever a new query is sent on the connection, we perform the draining of > the tuples to tuplestore if any or mark the other scan completed > appropriately. Sorry, that was my mistake. The temp keyword in the "CREATE TEMP TABLE" statement is unnecessary; just remove it directly. This crash has already been fixed in the v13 patch. LGTM. Best regards, -- Yilin Zhang
