Fix "invalid spinlock number: 0" error in pg_stat_wal_receiver.
authorFujii Masao <fujii@postgresql.org>
Thu, 18 Feb 2021 14:22:23 +0000 (23:22 +0900)
committerFujii Masao <fujii@postgresql.org>
Thu, 18 Feb 2021 14:28:15 +0000 (23:28 +0900)
commit614b7f18b3bda738f352a8732cf749eb5fa56dae
tree1c1c40cb74dabeb8150806015e647f79d79069d9
parenteb42110d952f8d1ad4049b8f2491e9dfba75ffed
Fix "invalid spinlock number: 0" error in pg_stat_wal_receiver.

Commit 2c8dd05d6c added the atomic variable writtenUpto into
walreceiver's shared memory information. It's initialized only
when walreceiver started up but could be read via pg_stat_wal_receiver
view anytime, i.e., even before it's initialized. In the server built
with --disable-atomics and --disable-spinlocks, this uninitialized
atomic variable read could cause "invalid spinlock number: 0" error.

This commit changed writtenUpto so that it's initialized at
the postmaster startup, to avoid the uninitialized variable read
via pg_stat_wal_receiver and fix the error.

Also this commit moved the read of writtenUpto after the release
of spinlock protecting walreceiver's shared variables. This is
necessary to prevent new spinlock from being taken by atomic
variable read while holding another spinlock, and to shorten
the spinlock duration. This change leads writtenUpto not to be
consistent with the other walreceiver's shared variables protected
by a spinlock. But this is OK because writtenUpto should not be
used for data integrity checks.

Back-patch to v13 where commit 2c8dd05d6c introduced the bug.

Author: Fujii Masao
Reviewed-by: Michael Paquier, Thomas Munro, Andres Freund
Discussion: https://postgr.es/m/7ef8708c-5b6b-edd3-2cf2-7783f1c7c175@oss.nttdata.com
src/backend/replication/walreceiver.c
src/backend/replication/walreceiverfuncs.c
src/test/regress/expected/sysviews.out
src/test/regress/sql/sysviews.sql