Обсуждение: bug/confusion with pg_log_standby_snapshot()

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.

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