Skip site navigation (1) Skip section navigation (2)

Re: exec_execute_message crash

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: exec_execute_message crash
Date: 2009-12-31 01:48:48
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> 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't release the portal's memory until the cleanup call.
 * The reason we need to reset active is so that we can replace the unnamed
 * portal, else we'll fail to execute ROLLBACK when it arrives.
	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

In response to


pgsql-hackers by date

Next:From: Andres FreundDate: 2009-12-31 02:38:01
Subject: Re: Hot Standy introduced problem with query cancel behavior
Previous:From: Greg SmithDate: 2009-12-31 01:40:09
Subject: Re: Thoughts on statistics for continuously advancing columns

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group