On Tue, Aug 9, 2016 at 12:22 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Aug 8, 2016 at 7:33 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Thomas Munro <thomas.mu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
