On Mon, Aug 8, 2016 at 7:33 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.mu...@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 which will
 * 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

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

Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to