pg.ddx.io pgsql-docs@postgresql.org mailing list archive
help / color / mirror / Atom feedInaccuracy in wal_receiver_status_interval parameter description
9+ messages / 4 participants
[nested] [flat]
* Inaccuracy in wal_receiver_status_interval parameter description
@ 2021-02-16 07:24 PG Doc comments form <noreply@postgresql.org>
2021-02-17 06:01 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 9+ messages in thread
From: PG Doc comments form @ 2021-02-16 07:24 UTC (permalink / raw)
To: pgsql-docs@lists.postgresql.org; +Cc: kuzmin.db4@gmail.com
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.
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Inaccuracy in wal_receiver_status_interval parameter description
2021-02-16 07:24 Inaccuracy in wal_receiver_status_interval parameter description PG Doc comments form <noreply@postgresql.org>
@ 2021-02-17 06:01 ` Michael Paquier <michael@paquier.xyz>
2021-02-20 09:49 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Dmitriy Kuzmin <kuzmin.db4@gmail.com>
0 siblings, 1 reply; 9+ messages in thread
From: Michael Paquier @ 2021-02-17 06:01 UTC (permalink / raw)
To: kuzmin.db4@gmail.com; pgsql-docs@lists.postgresql.org
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
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Inaccuracy in wal_receiver_status_interval parameter description
2021-02-16 07:24 Inaccuracy in wal_receiver_status_interval parameter description PG Doc comments form <noreply@postgresql.org>
2021-02-17 06:01 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Michael Paquier <michael@paquier.xyz>
@ 2021-02-20 09:49 ` Dmitriy Kuzmin <kuzmin.db4@gmail.com>
2021-02-21 06:58 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 9+ messages in thread
From: Dmitriy Kuzmin @ 2021-02-20 09:49 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: pgsql-docs@lists.postgresql.org
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>:
> 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
>
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Inaccuracy in wal_receiver_status_interval parameter description
2021-02-16 07:24 Inaccuracy in wal_receiver_status_interval parameter description PG Doc comments form <noreply@postgresql.org>
2021-02-17 06:01 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Michael Paquier <michael@paquier.xyz>
2021-02-20 09:49 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Dmitriy Kuzmin <kuzmin.db4@gmail.com>
@ 2021-02-21 06:58 ` Michael Paquier <michael@paquier.xyz>
2021-02-22 00:21 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Euler Taveira <euler@eulerto.com>
0 siblings, 1 reply; 9+ messages in thread
From: Michael Paquier @ 2021-02-21 06:58 UTC (permalink / raw)
To: Dmitriy Kuzmin <kuzmin.db4@gmail.com>; +Cc: pgsql-docs@lists.postgresql.org
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.patch (text/x-diff, 1.7K) download
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index e81141e45c..752466bb00 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -4503,15 +4503,16 @@ ANY <replaceable class="parameter">num_sync</replaceable> ( <replaceable class="
view. The standby will report
the last write-ahead log location it has written, the last position it
has flushed to disk, and the last position it has applied.
- This parameter's
- value is the maximum amount of time between reports. Updates are
- sent each time the write or flush positions change, or at least as
- often as specified by this parameter. Thus, the apply position may
- lag slightly behind the true position.
+ This parameter's value is the maximum amount of time between reports.
+ Updates are sent each time the write or flush positions change, or as
+ often as specified by this parameter if set to a non-zero value.
+ There are additional cases where updates are sent while ignoring this
+ parameter; for example, when processing of the existing WAL completes
+ or when <varname>synchronous_commit</varname> is set to
+ <literal>remove_apply</literal>.
+ Thus, the apply position may lag slightly behind the true position.
If this value is specified without units, it is taken as seconds.
- The default value is 10 seconds.
- Setting this parameter to zero disables status updates completely.
- This parameter can only be set in
+ The default value is 10 seconds. This parameter can only be set in
the <filename>postgresql.conf</filename> file or on the server
command line.
</para>
* Re: Inaccuracy in wal_receiver_status_interval parameter description
2021-02-16 07:24 Inaccuracy in wal_receiver_status_interval parameter description PG Doc comments form <noreply@postgresql.org>
2021-02-17 06:01 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Michael Paquier <michael@paquier.xyz>
2021-02-20 09:49 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Dmitriy Kuzmin <kuzmin.db4@gmail.com>
2021-02-21 06:58 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Michael Paquier <michael@paquier.xyz>
@ 2021-02-22 00:21 ` Euler Taveira <euler@eulerto.com>
2021-02-24 02:19 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 9+ messages in thread
From: Euler Taveira @ 2021-02-22 00:21 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; Dmitriy Kuzmin <kuzmin.db4@gmail.com>; +Cc: pgsql-docs@lists.postgresql.org
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/
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Inaccuracy in wal_receiver_status_interval parameter description
2021-02-16 07:24 Inaccuracy in wal_receiver_status_interval parameter description PG Doc comments form <noreply@postgresql.org>
2021-02-17 06:01 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Michael Paquier <michael@paquier.xyz>
2021-02-20 09:49 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Dmitriy Kuzmin <kuzmin.db4@gmail.com>
2021-02-21 06:58 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Michael Paquier <michael@paquier.xyz>
2021-02-22 00:21 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Euler Taveira <euler@eulerto.com>
@ 2021-02-24 02:19 ` Michael Paquier <michael@paquier.xyz>
2021-02-24 13:16 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Dmitriy Kuzmin <kuzmin.db4@gmail.com>
0 siblings, 1 reply; 9+ messages in thread
From: Michael Paquier @ 2021-02-24 02:19 UTC (permalink / raw)
To: Euler Taveira <euler@eulerto.com>; +Cc: Dmitriy Kuzmin <kuzmin.db4@gmail.com>; pgsql-docs@lists.postgresql.org
On Sun, Feb 21, 2021 at 09:21:41PM -0300, Euler Taveira wrote:
> LGTM.
Thanks, applied.
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Inaccuracy in wal_receiver_status_interval parameter description
2021-02-16 07:24 Inaccuracy in wal_receiver_status_interval parameter description PG Doc comments form <noreply@postgresql.org>
2021-02-17 06:01 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Michael Paquier <michael@paquier.xyz>
2021-02-20 09:49 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Dmitriy Kuzmin <kuzmin.db4@gmail.com>
2021-02-21 06:58 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Michael Paquier <michael@paquier.xyz>
2021-02-22 00:21 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Euler Taveira <euler@eulerto.com>
2021-02-24 02:19 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Michael Paquier <michael@paquier.xyz>
@ 2021-02-24 13:16 ` Dmitriy Kuzmin <kuzmin.db4@gmail.com>
2021-02-25 02:41 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 9+ messages in thread
From: Dmitriy Kuzmin @ 2021-02-24 13:16 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Euler Taveira <euler@eulerto.com>; pgsql-docs@lists.postgresql.org
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>:
> On Sun, Feb 21, 2021 at 09:21:41PM -0300, Euler Taveira wrote:
> > LGTM.
>
> Thanks, applied.
> --
> Michael
>
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Inaccuracy in wal_receiver_status_interval parameter description
2021-02-16 07:24 Inaccuracy in wal_receiver_status_interval parameter description PG Doc comments form <noreply@postgresql.org>
2021-02-17 06:01 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Michael Paquier <michael@paquier.xyz>
2021-02-20 09:49 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Dmitriy Kuzmin <kuzmin.db4@gmail.com>
2021-02-21 06:58 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Michael Paquier <michael@paquier.xyz>
2021-02-22 00:21 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Euler Taveira <euler@eulerto.com>
2021-02-24 02:19 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Michael Paquier <michael@paquier.xyz>
2021-02-24 13:16 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Dmitriy Kuzmin <kuzmin.db4@gmail.com>
@ 2021-02-25 02:41 ` Michael Paquier <michael@paquier.xyz>
2021-02-26 12:32 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Dmitriy Kuzmin <kuzmin.db4@gmail.com>
0 siblings, 1 reply; 9+ messages in thread
From: Michael Paquier @ 2021-02-25 02:41 UTC (permalink / raw)
To: Dmitriy Kuzmin <kuzmin.db4@gmail.com>; +Cc: Euler Taveira <euler@eulerto.com>; pgsql-docs@lists.postgresql.org
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
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Inaccuracy in wal_receiver_status_interval parameter description
2021-02-16 07:24 Inaccuracy in wal_receiver_status_interval parameter description PG Doc comments form <noreply@postgresql.org>
2021-02-17 06:01 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Michael Paquier <michael@paquier.xyz>
2021-02-20 09:49 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Dmitriy Kuzmin <kuzmin.db4@gmail.com>
2021-02-21 06:58 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Michael Paquier <michael@paquier.xyz>
2021-02-22 00:21 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Euler Taveira <euler@eulerto.com>
2021-02-24 02:19 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Michael Paquier <michael@paquier.xyz>
2021-02-24 13:16 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Dmitriy Kuzmin <kuzmin.db4@gmail.com>
2021-02-25 02:41 ` Re: Inaccuracy in wal_receiver_status_interval parameter description Michael Paquier <michael@paquier.xyz>
@ 2021-02-26 12:32 ` Dmitriy Kuzmin <kuzmin.db4@gmail.com>
0 siblings, 0 replies; 9+ messages in thread
From: Dmitriy Kuzmin @ 2021-02-26 12:32 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Euler Taveira <euler@eulerto.com>; pgsql-docs@lists.postgresql.org
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>:
> 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
>
^ permalink raw reply [nested|flat] 9+ messages in thread
end of thread, other threads:[~2021-02-26 12:32 UTC | newest]
Thread overview: 9+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-02-16 07:24 Inaccuracy in wal_receiver_status_interval parameter description PG Doc comments form <noreply@postgresql.org>
2021-02-17 06:01 ` Michael Paquier <michael@paquier.xyz>
2021-02-20 09:49 ` Dmitriy Kuzmin <kuzmin.db4@gmail.com>
2021-02-21 06:58 ` Michael Paquier <michael@paquier.xyz>
2021-02-22 00:21 ` Euler Taveira <euler@eulerto.com>
2021-02-24 02:19 ` Michael Paquier <michael@paquier.xyz>
2021-02-24 13:16 ` Dmitriy Kuzmin <kuzmin.db4@gmail.com>
2021-02-25 02:41 ` Michael Paquier <michael@paquier.xyz>
2021-02-26 12:32 ` Dmitriy Kuzmin <kuzmin.db4@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox