Tatsuo Ishii <is...@postgresql.org> writes: > parse causes transaction to abort, which causes call to > AbortCurrentTransaction->AbortTransaction->AtAbort_portals->ReleaseCachedPlan. > It > calls ReleaseCachePlan(portal->cplan). ReleaseCachePlan calls > MemoryContextDelete(plan->context) which destroys both portal->cplan > and portal->stmts.
> That was the reason why I had segfault by accessing portal->stmts. > To fix this I think exec_execute_message should throw an error if > portal->cleanup is NULL, since portal->cleanup is NULLed by > AtAbort_Portals at transaction abort (or portal is dropped). This is just a kluge, and a rather bad one I think. The real problem here is that AtAbort_Portals destroys the portal contents and doesn't do anything to record the fact. It should probably be putting the portal into PORTAL_FAILED state, and what exec_execute_message ought to be doing is checking for that. It might be a good idea to explicitly zero out the now-dangling pointers in the Portal struct, too. It'd be nice to have a test case for this, hint hint ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers