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

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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