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.
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