Peter Eisentraut <peter.eisentr...@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