Horton

Thread

Commits

  1. doc: Improve description of wal_receiver_status_interval

  1. Inaccuracy in wal_receiver_status_interval parameter description

    The Post Office <noreply@postgresql.org> — 2021-02-16T07:24:04Z

    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.

  2. Re: Inaccuracy in wal_receiver_status_interval parameter description

    Michael Paquier <michael@paquier.xyz> — 2021-02-17T06:01:18Z

    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

  3. Re: Inaccuracy in wal_receiver_status_interval parameter description

    Dmitriy Kuzmin <kuzmin.db4@gmail.com> — 2021-02-20T09:49:21Z

    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
>

  4. Re: Inaccuracy in wal_receiver_status_interval parameter description

    Michael Paquier <michael@paquier.xyz> — 2021-02-21T06:58:59Z

    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

  5. Re: Inaccuracy in wal_receiver_status_interval parameter description

    Euler Taveira <euler@eulerto.com> — 2021-02-22T00:21:41Z

    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/

  6. Re: Inaccuracy in wal_receiver_status_interval parameter description

    Michael Paquier <michael@paquier.xyz> — 2021-02-24T02:19:41Z

    On Sun, Feb 21, 2021 at 09:21:41PM -0300, Euler Taveira wrote:
> LGTM.

Thanks, applied.
--
Michael

  7. Re: Inaccuracy in wal_receiver_status_interval parameter description

    Dmitriy Kuzmin <kuzmin.db4@gmail.com> — 2021-02-24T13:16:57Z

    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
>

  8. Re: Inaccuracy in wal_receiver_status_interval parameter description

    Michael Paquier <michael@paquier.xyz> — 2021-02-25T02:41:47Z

    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

  9. Re: Inaccuracy in wal_receiver_status_interval parameter description

    Dmitriy Kuzmin <kuzmin.db4@gmail.com> — 2021-02-26T12:32:27Z

    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
>