> 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. 
