Below is a situation reproducible with version 13.1 and 13.2 (at least). At
the end of it, the streaming replication standby on startup does not connect
to the primary. It is unclear whether this is an issue, or whether the
standby will connect later on somehow and resume replication.
We have a customer who reported pg_last_wal_receive_lsn() returning NULL on
a delayed standby, and this is what the investigation led to. In their case
though, the standby was pulling in wal via restore_command and not
replicaton slots. Customer reports he can see changes in tables as expected,
with the appropriate delay. Primary and standby have been running well
Here are the steps to reproduce:
Step 1: Have a primary streaming-replicating to a standby via a replication
slot. Both primary and standby have default configurations from initdb,
port = 7000
port = 7001
hot_standby = on
primary_conninfo = 'port=7000'
primary_slot_name = 'slot1'
Step 2: Ensure standby is all caught up, and no ongoing changes in
postgres=# select slot_name, restart_lsn, active, active_pid from
slot_name | restart_lsn | active | active_pid
slot1 | 0/2EDFF8C8 | t | 28061