Обсуждение: [HACKERS] [PATCH] Document the order of changing certain settings when usinghot-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

-- 
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,

> 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

-- 
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,

> 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]. 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

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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
theseparameters    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
changesto 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

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