Re: Memory leak with CALL to Procedure with COMMIT.
От | Peter Eisentraut |
---|---|
Тема | Re: Memory leak with CALL to Procedure with COMMIT. |
Дата | |
Msg-id | a3b95af7-4cb4-a026-3dca-13a456ec8481@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Memory leak with CALL to Procedure with COMMIT. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Memory leak with CALL to Procedure with COMMIT.
|
Список | 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 по дате отправления: