Re: exec_execute_message crash

> 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