Hi Michael.
> The docs say only that:
> "Updates are sent each time the write or flush positions change, or at
> least as often as specified by this parameter."
A bit further it says "Setting this parameter to zero disables status
updates completely."
> So it could make sense to complete a bit this paragraph with some
> words about the places where WalRcvForceReply() or similar logic is
> used. The case of the end of the WAL stream ending would be an extra
> one. How would you formulate that and what are the cases you think
> would be worth mentioning?
I suppose it could be something like this:
"...Setting this parameter to zero disables status updates on a scheduled
basis completely. However there are certain conditions when updates are
still being sent. For example when startup process completes processing WAL
files or when standby is in synchronous mode and synchronous_commit is set
to remote_apply. This parameter can only be set in the postgresql.conf file
or on the server command line."
Best regards,
Dmitriy Kuzmin
ср, 17 февр. 2021 г. в 16:01, Michael Paquier :
> On Tue, Feb 16, 2021 at 07:24:04AM +, PG Doc comments form wrote:
> > The documentation says that setting wal_receiver_status_interval to 0
> > disable updates of replication status completely. However walreceiver
> keep
> > sending status in some cases. For example, when startup has finished
> > processing WALs and start waiting for more:
> >
> https://github.com/postgres/postgres/blob/master/src/backend/access/transam/xlog.c#L12598-L12609
> > It would be helpful to document in what cases status updates are still
> being
> > sent.
>
> The docs say only that:
> "Updates are sent each time the write or flush positions change, or at
> least as often as specified by this parameter."
>
> So it could make sense to complete a bit this paragraph with some
> words about the places where WalRcvForceReply() or similar logic is
> used. The case of the end of the WAL stream ending would be an extra
> one. How would you formulate that and what are the cases you think
> would be worth mentioning?
> --
> Michael
>
