Inaccuracy in wal_receiver_status_interval parameter description
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/12/runtime-config-replication.html
Description:
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.
On Tue, Feb 16, 2021 at 07:24:04AM +0000, 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
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 <michael@paquier.xyz>:
Show quoted text
On Tue, Feb 16, 2021 at 07:24:04AM +0000, PG Doc comments form wrote:
The documentation says that setting wal_receiver_status_interval to 0
disable updates of replication status completely. However walreceiverkeep
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
On Sat, Feb 20, 2021 at 07:49:21PM +1000, Dmitriy Kuzmin wrote:
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."
That's an idea. While looking at that I found confusing that the
sentence "Setting this parameter to zero disables status updates
completely" was completely separate of the rest, where it sounds like
even forced messages are disabled if the parameter value is zero, but
I think that we should outline that this only applies to the scheduled
replies. Attached is what I get. What do you think?
--
Michael
Attachments:
replay-status-docs.patchtext/x-diff; charset=us-asciiDownload+9-8
On Sun, Feb 21, 2021, at 3:58 AM, Michael Paquier wrote:
That's an idea. While looking at that I found confusing that the
sentence "Setting this parameter to zero disables status updates
completely" was completely separate of the rest, where it sounds like
even forced messages are disabled if the parameter value is zero, but
I think that we should outline that this only applies to the scheduled
replies. Attached is what I get. What do you think?
LGTM.
--
Euler Taveira
EDB https://www.enterprisedb.com/
On Sun, Feb 21, 2021 at 09:21:41PM -0300, Euler Taveira wrote:
LGTM.
Thanks, applied.
--
Michael
Thanks.
Will this change be made in the documentation for all Postgresql versions?
Best regards,
Dmitriy Kuzmin
ср, 24 февр. 2021 г. в 12:19, Michael Paquier <michael@paquier.xyz>:
Show quoted text
On Sun, Feb 21, 2021 at 09:21:41PM -0300, Euler Taveira wrote:
LGTM.
Thanks, applied.
--
Michael
On Wed, Feb 24, 2021 at 11:16:57PM +1000, Dmitriy Kuzmin wrote:
Will this change be made in the documentation for all Postgresql versions?
This wording has been introduced back in 2011 as of b186523, and
nobody complained about that until now, so I did not see a strong need
to back-patch it. Would people prefer a back-patch for that?
--
Michael
Hi Michael.
IMHO, if each supported version behaves as described in this paragraph,
then the patch should also be applied to the documentation for each version.
Best regards,
Dmitriy Kuzmin
чт, 25 февр. 2021 г. в 12:41, Michael Paquier <michael@paquier.xyz>:
Show quoted text
On Wed, Feb 24, 2021 at 11:16:57PM +1000, Dmitriy Kuzmin wrote:
Will this change be made in the documentation for all Postgresql
versions?
This wording has been introduced back in 2011 as of b186523, and
nobody complained about that until now, so I did not see a strong need
to back-patch it. Would people prefer a back-patch for that?
--
Michael