Re: Memory leak with CALL to Procedure with COMMIT.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
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-16 17:26:46
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> The problem arises with the combination of CALL with output parameters
> and doing a COMMIT inside the procedure.

> When a CALL has output parameters, the portal uses the strategy
> 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?

In the long run where we want to think about allowing multiple rowsets to
be returned out of a procedure, it's fairly likely that PORTAL_UTIL_SELECT
isn't going to work anyway. Maybe we should be thinking about inventing a
different portal execution strategy for CALL. But I'm not sure we need
that just yet.

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Jeremy Finzel 2018-08-16 17:53:26 Re: Repeatable Read Isolation in SQL running via background worker
Previous Message Andres Freund 2018-08-16 17:14:16 Re: Stored procedures and out parameters