From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: dsm_unpin_segment |
Date: | 2016-08-08 23:33:57 |
Message-ID: | 26048.1470699237@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)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.
I don't object to the concept, but you need a less half-baked
implementation if you want to add this. I'd suggest separate counters for
process attaches and pin requests, with code in dsm_unpin_segment to
disallow decrementing the pin request count below zero, and segment
destruction only when both counters go to zero.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-08-09 00:22:53 | Re: dsm_unpin_segment |
Previous Message | Tatsuo Ishii | 2016-08-08 22:56:09 | Re: Slowness of extended protocol |