Avoid exposing WAL receiver raw conninfo during timeline jumps
Michael Paquier <michael@paquier.xyz>
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
Files
| Path | Change | +/− |
|---|---|---|
| src/backend/replication/walreceiverfuncs.c | modified | +9 −5 |
| src/test/recovery/t/004_timeline_switch.pl | modified | +13 −2 |
Discussion
- Fix pg_stat_wal_receiver to show CONNECTING status 15 messages · 2026-05-19 → 2026-05-24