I've noticed that if the primary is started and then a base backup is immediately taken from it and started as as a synchronous standby, it doesn't replicate and the primary hangs indefinitely when trying to run any WAL-generating statements. It only recovers when either the primary is restarted (which has to use a fast shutdown otherwise it also hangs forever), or the standby is restarted.
Here's a way of reproducing it:
-------------------------------
mkdir -p -m 0700 primary standby1
initdb -N -k -D primary -E 'UTF8'
cat << PRIMARYCONFIG >> primary/postgresql.conf
shared_buffers = 8MB
logging_collector = on
log_line_prefix = '%m - %u - %d'
synchronous_standby_names = 'standby1'
max_connections = 8
wal_level = 'hot_standby'
port = 5530
max_wal_senders = 3
wal_keep_segments = 6
PRIMARYCONFIG
cat << PRIMARYHBA >> primary/pg_hba.conf
local replication rep_user trust
host replication rep_user
127.0.0.1/32 trust
host replication rep_user ::1/128 trust
PRIMARYHBA
pg_ctl start -D primary
psql -p 5530 -h localhost -c 'SET SESSION synchronous_commit TO 'off';CREATE USER rep_user REPLICATION;;' -d postgres
pg_basebackup -x -D standby1 -h localhost -p 5530 -U rep_user
cat << STANDBYCONFIG >> standby1/postgresql.conf
port = 5531
hot_standby = on
STANDBYCONFIG
cat << STANDBYRECOVERY >> standby1/recovery.conf
standby_mode = 'on'
recovery_target_timeline = 'latest'
primary_conninfo = 'host=127.0.0.1 user=rep_user port=5530 application_name=standby1'
STANDBYRECOVERY
pg_ctl -D standby1 start
-------------------------------
Note that if you run the commands one by one, there isn't a problem. If you run it as a script, the standby doesn't connect to the primary. There aren't any errors reported by either the standby or the primary. The primary's wal sender process reports the following:
wal sender process rep_user 127.0.0.1(45243) startup waiting for 0/3000158
Anyone know why this would be happening? And if this could be a problem in other scenarios?