Re: CurTransactionContext freed before transaction COMMIT ???

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