Error Reported in Thread [2]: This issue has been fixed by switching to a NULL resource owner before attaching to DSM in the CFI handler.
This error mentioned in thread [2] is triggered during CFI() call from secure_read() when a backend is waiting for commands and it has an open transaction which is going to abort
Below are some details about this fix.
It is safe to temporarily set the resource owner to NULL before attaching to the DSA and DSHASH, since these segments are intended to be attached for the full session and are detached only when the session ends. We also restore the original resource owner immediately after the attach completes.
After further discussion and reviewing Robert's email[1] on this topic, a safer solution is to avoid running ProcessGetMemoryContextInterrupt during an aborted transaction. This should help prevent additional errors when the transaction is already in error handling state. Also, reporting memory context statistics from an aborting transaction won't be very useful as some of that memory usage won't be valid after abort completes. Attached is the updated patch that addresses this.
Other possible fixes include:
1.Adjusting resource‑owner behavior Either allow resource‑owner enlargement during release, or delay marking it as releasing until the abort actually begins.
Sorry, this point is invalid as resource-owner is already being marked as releasing from AbortTransaction.
