]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Avoid exposing WAL receiver raw conninfo during timeline jumps
authorMichael Paquier <michael@paquier.xyz>
Fri, 22 May 2026 23:10:15 +0000 (08:10 +0900)
committerMichael Paquier <michael@paquier.xyz>
Fri, 22 May 2026 23:10:15 +0000 (08:10 +0900)
commite037a4199617a678ebeb68d2ba722c5ed1cfeb6f
tree6881e81a7251cd71bddd9e5644dad18b298fbcd4
parent9590dcfca498879678fe4d280f7b21fff0cbfff9
Avoid exposing WAL receiver raw conninfo during timeline jumps

When reusing an existing WAL receiver after it has reached
WALRCV_WAITING for new instructions, RequestXLogStreaming() copied
PrimaryConnInfo into WalRcv->conninfo before switching the state to
WALRCV_RESTARTING.  At that point ready_to_display could still be true,
so pg_stat_wal_receiver could expose the raw connection string,
including sensitive fields, but it should only show the user-displayable
version of the connection string.

WALRCV_RESTARTING does not establish a new connection.  The waiting WAL
receiver reuses its existing connection and only needs a new startpoint
and timeline, so there is no need to copy the raw connection string into
shared memory again.  Let's only copy conninfo when launching a new WAL
receiver after WALRCV_STOPPED, not while waiting for instructions.

This commit adds coverage for the case fixed by this commit to the
timeline-switch test by verifying that the WAL receiver conninfo remains
consistent across the jump.

Backpatch all the way down, as this issue is possible since
pg_stat_wal_receiver has been introduced.

Author: Chao Li <li.evan.chao@gmail.com>
Reviewed-by: Michael Paquier <michael@paquier.xyz>
Discussion: https://postgr.es/m/EF91FF76-1E2B-4F3B-9162-290B4DC517FF@gmail.com
Backpatch-through: 14
src/backend/replication/walreceiverfuncs.c
src/test/recovery/t/004_timeline_switch.pl