On Tue, Aug 9, 2016 at 12:22 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Aug 8, 2016 at 7:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Thomas Munro <thomas.munro@enterprisedb.com> writes:
>>> 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
> 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.
Yeah, I was considering unbalanced pin/unpin requests to be a
programming error. To be more defensive about that, how about I add a
boolean 'pinned' to dsm_control_item, and elog(ERROR, ...) if it's not
in the expected state when you try to pin or unpin?
--
Thomas Munro
http://www.enterprisedb.com
