Re: Latches with weak memory ordering (Re: max_wal_senders must die)
От | Tom Lane |
---|---|
Тема | Re: Latches with weak memory ordering (Re: max_wal_senders must die) |
Дата | |
Msg-id | 15085.1289837520@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Latches with weak memory ordering (Re: max_wal_senders must die) (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Latches with weak memory ordering (Re: max_wal_senders
must die)
|
Список | pgsql-hackers |
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes: > In SetLatch, is it enough to add the SpinLockAcquire() call *after* > checking that is_set is not already set? Ie. still do the quick exit > without holding a lock. Or do we need a memory barrier operation before > the fetch, to ensure that we see if the other process has just cleared > the flag with ResetLatch() ? Presumable ResetLatch() needs to call > SpinLockAcquire() anyway to ensure that other processes see the clearing > of the flag. Hmm ... I just remembered the reason why we didn't use a spinlock in these functions already. Namely, that it's unsafe for a signal handler to try to acquire a spinlock that the interrupted code might be holding. So I think a bit more thought is needed here. Maybe we need to bite the bullet and do memory barriers ... regards, tom lane
В списке pgsql-hackers по дате отправления: