On Thu, 16 Jul 2026 at 12:24, Yilin Zhang <[email protected]> wrote:
> 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. > Nevertheless, your input was valuable in finding the issue and fixing it. > This crash has already been fixed in the v13 patch. > LGTM. > > Hey, thanks a lot for confirming this. > > > Best regards, > -- > Yilin Zhang > > > -- Regards, Rafia Sabih CYBERTEC PostgreSQL International GmbH
