This sounds broken on its face --- if you want stuff to survive to
top-level commit, you need to keep it in TopTransactionContext.
CurTransactionContext might be a subtransaction's context that will
go away at subtransaction commit/abort.
https://github.com/postgres/postgres/blob/master/src/backend/utils/mmgr/README
>From the above README:
CurTransactionContext --- this holds data that has to survive until the end
of the current transaction, and in particular will be needed at top-level
transaction commit. When we are in a top-level transaction this is the same
as TopTransactionContext, but in subtransactions it points to a child context.
It is important to understand that if a subtransaction aborts, its
CurTransactionContext is thrown away after finishing the abort processing;
but a committed subtransaction's CurTransactionContext is kept until top-level
commit (unless of course one of the intermediate levels of subtransaction
aborts). This ensures that we do not keep data from a failed subtransaction
longer than necessary. Because of this behavior, you must be careful to clean
up properly during subtransaction abort --- the subtransaction's state must be
delinked from any pointers or lists kept in upper transactions, or you will
have dangling pointers leading to a crash at top-level commit. An example of
data kept here is pending NOTIFY messages, which are sent at top-level commit,
but only if the generating subtransaction did not abort.
--> So even if sub-transaction is committed, subtransaction's
CurTransactionContext is kept until top-level commit.
--> If sub-transaction is aborted, we handled(clearing the data) it via
RegisterSubXactCallback().
And in our particular use case(which gave segmentation fault), we didn't issue
any sub-transaction. It was a single insert transaction.
Even then it resulted in some kind of context free.
Regards
G. Sai Ram
