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

From Tom Lane
Subject Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)
Date
Msg-id 26753.1283537761@sss.pgh.pa.us
Whole thread Raw
In response to Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> On 03/09/10 17:51, Tom Lane wrote:
>> If there is *any* possibility of that happening then you have far worse
>> problems than whether the field is atomically readable or not: the
>> behavior will be unpredictable at just slightly larger timescales.

> Each Walsender needs a latch, and walsenders come and go.

Well, then we need to think extremely hard about the circumstances in
which we need to send a cross-process latch signal to walsenders and
what the behavior needs to be in the race conditions.

> WaitLatch had to set the pid on the Latch struct to allow other 
> processes to send the signal. Another process could call SetLatch and 
> read the pid field, while WaitLatch is just setting it. I think we'll 
> have to put a spinlock there, if we can't assume that assignment of 
> pid_t is atomic. It's not the end of the world..

Yes it is.  Signal handlers can't take spinlocks (what if they interrupt
while the mainline is holding the lock?).

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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Cost estimates for parameterized paths
Next
From: Alexey Klyukin
Date:
Subject: ps buffer is incorrectly padded on the (latest) OS X