Re: pg_upgrade instructions involving "rsync --size-only" might lead to standby corruption?

From: Nikolay Samokhvalov <nik(at)postgres(dot)ai>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
Subject: Re: pg_upgrade instructions involving "rsync --size-only" might lead to standby corruption?
Date: 2023-07-10 20:36:39
Message-ID: CAM527d_-YmKqFfJmnPsVSeqKC_WHoJVQwxtNvUiV4ju+9stDpA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 7, 2023 at 6:31 AM Stephen Frost <sfrost(at)snowman(dot)net> wrote:

> * Nikolay Samokhvalov (nik(at)postgres(dot)ai) wrote:
> > But this can happen with anyone who follows the procedure from the docs
> as
> > is and doesn't do any additional steps, because in step 9 "Prepare for
> > standby server upgrades":
> >
> > 1) there is no requirement to follow specific order to shut down the
> nodes
> > - "Streaming replication and log-shipping standby servers can remain
> > running until a later step" should probably be changed to a
> > requirement-like "keep them running"
>
> Agreed that it would be good to clarify that the primary should be shut
> down first, to make sure everything written by the primary has been
> replicated to all of the replicas.
>

Thanks!

Here is a patch to fix the existing procedure description.

I agree with Andrey – without it, we don't have any good way to upgrade
large clusters in short time. Default rsync mode (without "--size-only")
takes a lot of time too, if the load is heavy.

With these adjustments, can "rsync --size-only" remain in the docs as the
*fast* and safe method to upgrade standbys, or there are still some
concerns related to corruption risks?

Attachment Content-Type Size
pg-upgrade-docs-clarify-rsync-size-only.patch application/octet-stream 3.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joseph Koshakow 2023-07-10 20:46:07 Re: Preventing non-superusers from altering session authorization
Previous Message Nathan Bossart 2023-07-10 20:31:58 Re: Preventing non-superusers from altering session authorization