Re: Memory leak with CALL to Procedure with COMMIT. - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Memory leak with CALL to Procedure with COMMIT.
Date
Msg-id a3b95af7-4cb4-a026-3dca-13a456ec8481@2ndquadrant.com
Whole thread Raw
In response to Re: Memory leak with CALL to Procedure with COMMIT.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Memory leak with CALL to Procedure with COMMIT.
List pgsql-hackers
On 16/08/2018 19:26, Tom Lane wrote:
>> When a CALL has output parameters, the portal uses the strategy
>> PORTAL_UTIL_SELECT instead of PORTAL_MULTI_QUERY.  Using
>> PORTAL_UTIL_SELECT causes the portal's snapshot to be registered with
>> the current resource owner (portal->holdSnapshot).  I'm not sure why
>> this is done for one kind of portal strategy but not the other.

> I'm a bit confused by that statement.  AFAICS, for both PortalRunUtility
> and PortalRunMulti, setHoldSnapshot is only passed as true by
> FillPortalStore, so registering the snapshot should happen (or not) the
> same way for either portal execution strategy.  What scenarios are you
> comparing here, exactly?

The call to PortalRunMulti() in FillPortalStore() is for
PORTAL_ONE_RETURNING and PORTAL_ONE_MOD_WITH, not for
PORTAL_MULTI_QUERY.  For PORTAL_MULTI_QUERY, FillPortalStore() isn't
called; PortalRun() calls PortalRunMulti() directly with setHoldSnapshot
= false.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Pre-v11 appearances of the word "procedure" in v11 docs
Next
From: Tomas Vondra
Date:
Subject: Re: [PATCH] Improve geometric types