Re: dsm_unpin_segment - Mailing list pgsql-hackers

From Tom Lane
Subject Re: dsm_unpin_segment
Date
Msg-id 28596.1470704024@sss.pgh.pa.us
Whole thread Raw
In response to Re: dsm_unpin_segment  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: dsm_unpin_segment  (Thomas Munro <thomas.munro@enterprisedb.com>)
Re: dsm_unpin_segment  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Thomas Munro <thomas.munro@enterprisedb.com> writes:
> 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?

Well, what you have there is a one-bit-wide pin request counter.
I do not see why that's better than an actual counter, but if that's
what you want to do, fine.

The larger picture here is that Robert is exhibiting a touching but
unfounded faith that extensions using this feature will contain zero bugs.
IMO there needs to be some positive defense against mistakes in using the
pin/unpin API.  As things stand, multiple pin requests don't have any
fatal consequences (especially not on non-Windows), so I have little
confidence that it's not happening in the field.  I have even less
confidence that there wouldn't be too many unpin requests.  What exactly
is an extension going to be doing to ensure that it doesn't do too many of
one or the other?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: dsm_unpin_segment
Next
From: "Tsunakawa, Takayuki"
Date:
Subject: Re: Wait events monitoring future development