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: 4C848B2A.9090102@enterprisedb.com (view raw or flat)
Thread:
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
   EnterpriseDB   http://www.enterprisedb.com

In response to

Responses

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-2014 The PostgreSQL Global Development Group