[PATCH] Document the order of changing certain settings when using hot-standby servers
The attached patch updates the hot-standby documentation (in the high
availability section) so it explicitly mentions that certain settings
need to be applied to servers in a particular order. For example, it
states that if you increase a certain setting (e.g. max_connections) you
need to do so on a primary first, before applying it to any secondaries.
Previously this was not explicitly mentioned and could lead to one
thinking they can just apply the setting to all servers in parallel,
resulting in standby servers refusing to start.
The exact phrasing currently used in the patch may be a bit rough, I'm
open to suggestions on how to best improve the writing.
The patch is based on the master branch and applies cleanly to it.
Yorick
Attachments:
document-hot-standby-config-order.patchtext/x-patch; name=document-hot-standby-config-order.patchDownload
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 51359d6236..bbb0e1aab2 100644
*** a/doc/src/sgml/high-availability.sgml
--- b/doc/src/sgml/high-availability.sgml
***************
*** 2098,2104 **** LOG: database system is ready to accept read only connections
be equal to or greater than the value on the primary. If these parameters
are not set high enough then the standby will refuse to start.
Higher values can then be supplied and the server
! restarted to begin recovery again. These parameters are:
<itemizedlist>
<listitem>
--- 2098,2108 ----
be equal to or greater than the value on the primary. If these parameters
are not set high enough then the standby will refuse to start.
Higher values can then be supplied and the server
! restarted to begin recovery again. If you want to increase these values you
! should do so on the primary first, before applying the changes to any
! standby servers. If you instead want to decrease these values you should do
! so on the standbys first, before applying the changes to the primary. These
! parameters are:
<itemizedlist>
<listitem>
Hi Yorick,
The attached patch updates the hot-standby documentation (in the high
availability section) so it explicitly mentions that certain settings
need to be applied to servers in a particular order. For example, it
states that if you increase a certain setting (e.g. max_connections)
you need to do so on a primary first, before applying it to any
secondaries.
I'm sorry to inform you that your description of max_connection is,
lets say, not quite accurate. I've just increased max_connections on a
standby without doing anything on a master and nothing wrong happened.
--
Best regards,
Aleksander Alekseev
Aleksander, Yorick,
* Aleksander Alekseev (a.alekseev@postgrespro.ru) wrote:
The attached patch updates the hot-standby documentation (in the high
availability section) so it explicitly mentions that certain settings
need to be applied to servers in a particular order. For example, it
states that if you increase a certain setting (e.g. max_connections)
you need to do so on a primary first, before applying it to any
secondaries.I'm sorry to inform you that your description of max_connection is,
lets say, not quite accurate. I've just increased max_connections on a
standby without doing anything on a master and nothing wrong happened.
Right, the logic there is reversed- reduction has to be done on the
primary first and then WAL replayed on the replica, while increasing has
to be done on the secondary first and then on the primary.
I do think that we should add the (correct!) information into the docs
explicitly, perhaps even as a 'Note', since it can be quite confusing
otherwise.
Thanks!
Stephen
Ha! It seems I indeed had it the other way around. I suppose that's what
happens when writing a patch late at night. Somewhat ironically I did
have the other correct in my Git commit message.
Attached is an updated version of the patch that corrects the order in
the documentation.
Yorick
Attachments:
document-hot-standby-config-order-with-correct-ordering.patchtext/x-patch; name=document-hot-standby-config-order-with-correct-ordering.patchDownload
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 51359d6236..434afe5d43 100644
*** a/doc/src/sgml/high-availability.sgml
--- b/doc/src/sgml/high-availability.sgml
***************
*** 2098,2104 **** LOG: database system is ready to accept read only connections
be equal to or greater than the value on the primary. If these parameters
are not set high enough then the standby will refuse to start.
Higher values can then be supplied and the server
! restarted to begin recovery again. These parameters are:
<itemizedlist>
<listitem>
--- 2098,2108 ----
be equal to or greater than the value on the primary. If these parameters
are not set high enough then the standby will refuse to start.
Higher values can then be supplied and the server
! restarted to begin recovery again. If you want to increase these values you
! should do so on any standby servers first, before applying the changes to
! the primary. If you instead want to decrease these values you should do so
! on the primary first, before applying the changes to any standby servers.
! These parameters are:
<itemizedlist>
<listitem>
Hi Yorick,
Attached is an updated version of the patch that corrects the order in
the documentation.
Looks promising. I would recommend to add this patch to the next
commitfest [1]https://commitfest.postgresql.org/14/. Otherwise there is a chance that it will be lost.
[1]: https://commitfest.postgresql.org/14/
--
Best regards,
Aleksander Alekseev
Done! It can be found at https://commitfest.postgresql.org/14/1110/
Thanks for reviewing thus far :)
Yorick
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi Yorick,
should do so on any standby servers first, before applying the changes to
What you actually meant probably was "do so on ALL standby servers
first", right?
--
Best regards,
Aleksander Alekseev
Aleksander,
What you actually meant probably was "do so on ALL standby servers
first", right?
Good point, right now it can give you the idea that applying it to just
1 standby (instead of all of them) is good enough, when instead you
need to apply it to all of them.
Attached is an adjusted version of my changes to better reflect this.
Yorick
Attachments:
document-hot-standby-config-order-mentioning-all-standby-servers.patchtext/x-patch; name=document-hot-standby-config-order-mentioning-all-standby-servers.patchDownload
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 51359d6236..8f382d0b93 100644
*** a/doc/src/sgml/high-availability.sgml
--- b/doc/src/sgml/high-availability.sgml
***************
*** 2098,2104 **** LOG: database system is ready to accept read only connections
be equal to or greater than the value on the primary. If these parameters
are not set high enough then the standby will refuse to start.
Higher values can then be supplied and the server
! restarted to begin recovery again. These parameters are:
<itemizedlist>
<listitem>
--- 2098,2108 ----
be equal to or greater than the value on the primary. If these parameters
are not set high enough then the standby will refuse to start.
Higher values can then be supplied and the server
! restarted to begin recovery again. If you want to increase these values you
! should do so on all standby servers first, before applying the changes to
! the primary. If you instead want to decrease these values you should do so
! on the primary first, before applying the changes to all standby servers.
! These parameters are:
<itemizedlist>
<listitem>
On Thu, Apr 13, 2017 at 8:29 AM, Yorick Peterse <yorickpeterse@gmail.com> wrote:
Good point, right now it can give you the idea that applying it to just
1 standby (instead of all of them) is good enough, when instead you
need to apply it to all of them.Attached is an adjusted version of my changes to better reflect this.
To me, this just seems redundant. The existing documentation already says:
For these parameters,
the value on the standby must
be equal to or greater than the value on the primary. If these parameters
are not set high enough then the standby will refuse to start.
Now you're proposing to add:
If you want to increase these values you
should do so on all standby servers first, before applying the changes to
the primary. If you instead want to decrease these values you should do so
on the primary first, before applying the changes to all standby servers.
But that's just the obvious logical consequence of the existing statement.
If we're going to add this text, I'd move it one sentence earlier and
stick "Therefore, " at the beginning. But it strikes me that it's
just a bet that if we say things twice instead of once, people will
pay more attention -- which is maybe true, but if that's done on a
widespread basis, it will cause the documentation to become bloated.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 9/1/17 13:00, Robert Haas wrote:
Now you're proposing to add:
If you want to increase these values you
should do so on all standby servers first, before applying the changes to
the primary. If you instead want to decrease these values you should do so
on the primary first, before applying the changes to all standby servers.But that's just the obvious logical consequence of the existing statement.
If we're going to add this text, I'd move it one sentence earlier and
stick "Therefore, " at the beginning.
Committed incorporating that suggestion.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers