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.
createdb
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/13/tutorial-createdb.html Description: In the getting started documentation, it will have been better to start with how to 'login to postgres' and cover the idea of 'roles'. Or if previously done, refer reader to the relevant section. The explanation on how to use createdb command can follow. This can avoid considerable problems for a user following the tutorial.
Re: Inaccuracy in wal_receiver_status_interval parameter description
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 signature.asc Description: PGP signature
