Re: dsm_unpin_segment

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

In response to

Responses

Browse pgsql-hackers by date

  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