From: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: portal pinning |
Date: | 2018-01-08 20:27:56 |
Message-ID: | 615be58b-2125-ee96-0e65-71401fbd565d@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/15/2017 03:36 PM, Peter Eisentraut wrote:
> On 12/12/17 10:34, Peter Eisentraut wrote:
>> But I also wonder whether we shouldn't automatically pin/unpin portals
>> in SPI_cursor_open() and SPI_cursor_close(). This makes sense if you
>> consider "pinned" to mean "internally generated". I don't think there
>> is a scenario in which user code should directly operate on a portal
>> created by SPI.
> Here is a patch for this option.
>
> The above sentence was not quite correct. Only unnamed portals should
> be pinned automatically. Named portals are of course possible to be
> passed around as refcursors for example.
>
This seems like a good idea, and the code change is tiny and clean. I
don't know of any third party PLs or other libraries might be pinning
the portals already on their own. How would they be affected if they did?
Anyway, marking ready for committer.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2018-01-08 20:28:55 | Re: [HACKERS] VACUUM and ANALYZE disagreeing on what reltuples means |
Previous Message | Robert Haas | 2018-01-08 20:27:35 | Re: Condition variable live lock |