> 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.
Yeah I thought about that too. in AtAbort_Portals:
--------------------------------------------------------------------------
/** Abort processing for portals.** At this point we reset "active" status and run the cleanup hook if* present, but we
can'trelease the portal's memory until the cleanup call.** The reason we need to reset active is so that we can replace
theunnamed* portal, else we'll fail to execute ROLLBACK when it arrives.*/
void
AtAbort_Portals(void)
{HASH_SEQ_STATUS status;PortalHashEnt *hentry;
hash_seq_init(&status, PortalHashTable);
while ((hentry = (PortalHashEnt *) hash_seq_search(&status)) != NULL){ Portal portal = hentry->portal;
if (portal->status == PORTAL_ACTIVE) portal->status = PORTAL_FAILED;
--------------------------------------------------------------------------
Should I change the last if clause to?
if (portal->status == PORTAL_ACTIVE || portal->status == PORTAL_READY) portal->status = PORTAL_FAILED;
> zero out the now-dangling pointers in the Portal struct, too.
portal->cplan is already zero out by PortalReleaseCachedPlan. Problem
is, portal->stmts may belong to PortalContext or others (in this
particluar case). So if we want to zero out portal->stmts, we need to
memorize the memory context which it belongs to and we need add a new
struct member to portal. I'm afraid this is an overkill...
> It'd be nice to have a test case for this, hint hint ...
Still working on...
--
Tatsuo Ishii
SRA OSS, Inc. Japan
