Fix double free of TupleSort memory context
Fix double free of TupleSort memory context

This is a forward port of commit 0043ae4f from 5X, with the test
removed, since it did not reproduce in 7X. In fact, it is unlikely for
this bug to occur in 7X because QueryFinishPending does not get checked
in between ExecReScanSort() and ExecSort() in many cases. This behavior
is different from 5X. However, a crash can still theoretically occur in
7X, and its better to patch this, even without a repro/test since the
fix is fairly simple.

Notes from 5X commit:

To trigger this bug, we need plan with a Sort node in a subplan that is
executed at least twice (viz. if there are multiple tuples on the outer
side).  Moreover, the QD must do a PQrequestFinish(), which sets
QueryFinishPending on all the QE processes, after the ExecRescanSort()
is executed, but before the next ExecSort(). This leaves the sort state
in an inconsistent state where node->tuplesortstate->sortstore != NULL,
but has already been freed. So another attempt to free it (in
ExecEndSort for example) will cause a crash.

This commit fixes this logic by setting the sortstore to NULL during
ExecRescanSort.

Co-authored-by: Shreedhar Hardikar <a657aa6fe6df17a9d181476831de52530bd87b81@vmware.com>
Co-authored-by: Alexandra Wang <2104ed7b77de63c11d65f08ed993b286192143d2@pivotal.io>

adam8157/gpdb,lisakowen/gpdb,greenplum-db/gpdb,xinzweb/gpdb,50wu/gpdb,xinzweb/gpdb,xinzweb/gpdb,50wu/gpdb,xinzweb/gpdb,xinzweb/gpdb,50wu/gpdb,lisakowen/gpdb,lisakowen/gpdb,adam8157/gpdb,50wu/gpdb,adam8157/gpdb,greenplum-db/gpdb,lisakowen/gpdb,adam8157/gpdb,50wu/gpdb,50wu/gpdb,lisakowen/gpdb,50wu/gpdb,greenplum-db/gpdb,xinzweb/gpdb,adam8157/gpdb,greenplum-db/gpdb,xinzweb/gpdb,adam8157/gpdb,lisakowen/gpdb,lisakowen/gpdb,greenplum-db/gpdb,lisakowen/gpdb,adam8157/gpdb,greenplum-db/gpdb,adam8157/gpdb,greenplum-db/gpdb,50wu/gpdb,greenplum-db/gpdb,xinzweb/gpdb