| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, Prabhat Sahu <prabhat(dot)sahu(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Memory leak with CALL to Procedure with COMMIT. |
| Date: | 2018-08-17 14:27:19 |
| Message-ID: | a3b95af7-4cb4-a026-3dca-13a456ec8481@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2018-08-17 14:40:20 | Re: [PATCH] Improve geometric types |
| Previous Message | Peter Eisentraut | 2018-08-17 14:15:00 | Re: Pre-v11 appearances of the word "procedure" in v11 docs |