From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
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-03 18:50:26 |
Message-ID: | 27380.1283539826@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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. 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?
This amount of complexity might be overkill for local latches, but I
think we need it for shared ones.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-09-03 19:00:27 | Re: ps buffer is incorrectly padded on the (latest) OS X |
Previous Message | Heikki Linnakangas | 2010-09-03 18:43:23 | Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!) |