Re: Segmentation fault with core dump

On 2013-04-10 19:29:06 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2013-04-10 19:06:12 -0400, Tom Lane wrote:
> >> And the answer is they're not testing this code path at all, because if
> >> you do
> >> DECLARE c CURSOR WITH HOLD FOR ...
> >> FETCH ALL FROM c;
> >> then the second query executes with a portal (and resource owner)
> >> created to execute the FETCH command, not directly on the held portal.
>
> > But in that path CurrentResourceOwner gets reset to portal->resowner as
> > well (see PortalRunFetch())?
>
> Right, but that's the FETCH's portal, which is a regular "live" portal
> that has a ResOwner.

I don't think so?

standard_ProcessUtility:
PerformPortalFetch:
    /* get the portal from the portal name */
    portal = GetPortalByName(stmt->portalname);
        ...
    /* Do it */
    nprocessed = PortalRunFetch(portal,
                                stmt->direction,
                                stmt->howMany,
                                dest);
PortalRunFetch:
    PG_TRY();
    {
        ActivePortal = portal;
        CurrentResourceOwner = portal->resowner;

So it seems to trigger a very similar codepath?

Greetings,

Andres Freund

--
 Andres Freund                       http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services