Re: ERROR: invalid spinlock number: 0
От | Fujii Masao |
---|---|
Тема | Re: ERROR: invalid spinlock number: 0 |
Дата | |
Msg-id | 918a47fc-e1fa-0c99-15e3-59b520455fe0@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: ERROR: invalid spinlock number: 0 (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: ERROR: invalid spinlock number: 0
|
Список | pgsql-hackers |
On 2021/02/16 6:28, Andres Freund wrote: > Hi, > > On 2021-02-15 19:45:21 +0900, Michael Paquier wrote: >> On Mon, Feb 15, 2021 at 10:47:05PM +1300, Thomas Munro wrote: >>> Why not initialise it in WalRcvShmemInit()? >> >> I was thinking about doing that as well, but we have no real need to >> initialize this stuff in most cases, say standalone deployments. In >> particular for the fallback implementation of atomics, we would >> prepare a spinlock for nothing. > > So what? It's just about free to initialize a spinlock, whether it's > using the fallback implementation or not. Initializing upon walsender > startup adds a lot of complications, because e.g. somebody could already > hold the spinlock because the previous walsender just disconnected, and > they were looking at the stats. Even if we initialize "writtenUpto" in WalRcvShmemInit(), WalReceiverMain() still needs to initialize (reset to 0) by using pg_atomic_write_u64(). Basically we should not acquire new spinlock while holding another spinlock, to shorten the spinlock duration. Right? If yes, we need to move pg_atomic_read_u64() of "writtenUpto" after the release of spinlock in pg_stat_get_wal_receiver. Attached is the updated version of the patch. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
Вложения
В списке pgsql-hackers по дате отправления: