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.
> take noticeable time. This can be sped up by calling the
> pg_log_standby_snapshot function on the primary.
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
