Skip site navigation (1) Skip section navigation (2)

Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)
Date: 2010-09-06 06:33:14
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 03/09/10 21:50, Tom Lane wrote:
> Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)com>  writes:
>> On 03/09/10 21:16, Tom Lane wrote:
>>> It's probably not too unreasonable to assume that pid_t assignment is
>>> atomic.  But I'm still thinking that we have bigger problems than that
>>> if there are really cases where SetLatch can execute at approximately
>>> the same time as a latch owner is coming or going.
>> I don't see how to avoid it. A walsender, or any process really, can
>> exit at any time. It can make the latch inaccessible to others before it
>> exits to minimize the window, but it's always going to be possible that
>> another process is just about to call SetLatch when you exit.
> Well, in that case what we need to do is presume that the latch object
> has a continuing existence but the owner/receiver can come and go.
> I would suggest that InitLatch needs to initialize the object into a
> valid but unowned state; there is *no* deinitialize operation; and
> there are AcquireLatch and ReleaseLatch operations to become owner
> or stop being owner.

I think we have just a terminology issue. What you're describing is 
exactly how it works now, if you just s/InitLatch/AcquireLatch. At the 
moment there's no need for an initialization function other than the 
InitLatch/AcquireLatch that associates the latch with the current 
process. I can add one for the sake of future-proofing, and to have 
better-defined behavior for setting a latch that has not been owned by 
anyone yet, but it's not strictly necessary.

>  We also need to define the semantics of SetLatch
> on an unowned latch --- does this set a signal condition that will be
> available to the next owner?

At the moment, no. Perhaps that would be useful, separating the Init and 
Acquire operations is needed to make that sane.

   Heikki Linnakangas

In response to


pgsql-hackers by date

Next:From: Pavel StehuleDate: 2010-09-06 06:37:18
Subject: Re: string function - "format" function proposal
Previous:From: Itagaki TakahiroDate: 2010-09-06 05:16:44
Subject: Re: string function - "format" function proposal

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group