Re: ERROR: invalid spinlock number: 0
Fujii Masao <masao.fujii@oss.nttdata.com>
From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Andres Freund <andres@anarazel.de>, Michael Paquier <michael@paquier.xyz>
Cc: Thomas Munro <thomas.munro@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2021-02-16T03:43:42Z
Lists: pgsql-hackers
Attachments
- bugfix_pg_stat_wal_receiver_v2.patch (text/plain) patch v2
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
Commits
-
Fix "invalid spinlock number: 0" error in pg_stat_wal_receiver.
- d4b667e9353a 13.3 landed
- 614b7f18b3bd 14.0 landed
-
Display the time when the process started waiting for the lock, in pg_locks, take 2
- 46d6e5f56790 14.0 cited
-
Display the time when the process started waiting for the lock, in pg_locks.
- 3b733fcd0419 14.0 cited
-
Make pg_stat_wal_receiver consistent with the WAL receiver's shmem info
- 2c8dd05d6cbc 13.0 cited