On Mon, Aug 8, 2016 at 7:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@enterprisedb.com> writes:
>> DSM segments have a concept of 'pinning'. Normally, segments are
>> destroyed when they are no longer mapped by any backend, using a
>> reference counting scheme. If you call dsm_pin_segment(segment), that
>> is disabled so that the segment won't be destroyed until the cluster
>> is shut down. It works by incrementing the reference count an extra
>> time.
>
>> Please find attached a patch to add a corresponding operation
>> 'dsm_unpin_segment'. This gives you a way to ask for the segment to
>> survive only until you decide to unpin it, at which point the usual
>> reference counting semantics apply again. It decrements the reference
>> count, undoing the effect of dsm_pin_segment and destroying the
>> segment if appropriate.
>
> What happens if dsm_unpin_segment is called more times than
> dsm_pin_segment? Seems like you could try to destroy a segment that
> still has processes attached.
Calling dsm_pin_segment more than once is not supported and has never
been supported. As the comments explain:
* This function should not be called more than once per segment;* on Windows, doing so will create unnecessary handles
whichwill* consume system resources to no benefit.
Therefore, I don't see the problem. You can pin a segment that is not
pinned, and you can unpin a segment that is pinned. You may not
re-pin a segment that is already pinned, nor unpin a segment that is
not pinned. If you try to do so, you are using the API contrary to
specification, and if it breaks (as it will) you get to keep both
pieces.
We could add the reference counting behavior for which you are asking,
but that seems to be an entirely new feature for which I know of no
demand.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
