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

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)
Дата
Msg-id 4C8141CB.7010102@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 03/09/10 21:16, Tom Lane wrote:
> Heikki Linnakangas<heikki.linnakangas@enterprisedb.com>  writes:
>> 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?).

Ok, I see.

> 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.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: Windows Tools
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)