Peter Eisentraut <peter.eisentraut@2ndquadrant.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 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?
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