Is pg_log_standby_snapshot() expected to cause a WAL segment to be emitted in an otherwise idle system? In my lab setup, the primary did not, despite invoking pg_log_standby_snapshot() on it, even when several times the archive_timeout value passed after using that function.
The setup was all Postgres 16.1, with a primary replicating to standby via log-shipping, and the standby (trying to) have a logical replication publication subscribed by a third Postgres server. In two separate trial runs, long waits happened on an idle system after invoking pg_log_standby_snapshot(). The function did not result in a new WAL segment being shipped to the standby, so on the third server the CREATE SUBSCRIPTION command hung until I eventually restarted the primary. At that point CREATE SUBSCRIPTION completed and everything began working. The documentation says: > If the primary is idle, creating a logical slot on standby may > take noticeable time. This can be sped up by calling the > pg_log_standby_snapshot function on the primary. https://www.postgresql.org/docs/current/logicaldecoding-explanation.html#LOGICALDECODING-REPLICATION-SLOTS Using the function wasn't enough. Should I have done more to trigger WAL emission? If so, directly stating that in the documentation would have helped me, and maybe others. Thanks, Pete
