Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line

From: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
To: Alexey Kondratov <a(dot)kondratov(at)postgrespro(dot)ru>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Liudmila Mantrova <l(dot)mantrova(at)postgrespro(dot)ru>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, David Steele <david(at)pgmasters(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, vladimirlesk(at)yandex-team(dot)ru, dsarafan(at)yandex-team(dot)ru
Subject: Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line
Date: 2020-01-18 15:21:22
Message-ID: CAPpHfduUqKLr2CRpcpHcv1qjaz+-+i9bOL2AOvdWSr954ti8Xw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi!

On Tue, Dec 3, 2019 at 12:41 PM Alexey Kondratov
<a(dot)kondratov(at)postgrespro(dot)ru> wrote:
> On 01.12.2019 5:57, Michael Paquier wrote:
> > On Thu, Sep 26, 2019 at 03:08:22PM +0300, Alexey Kondratov wrote:
> >> As Alvaro correctly pointed in the nearby thread [1], we've got an
> >> interference regarding -R command line argument. I agree that it's a good
> >> idea to reserve -R for recovery configuration write to be consistent with
> >> pg_basebackup, so I've updated my patch to use another letters:
> > The patch has rotten and does not apply anymore. Could you please
> > send a rebased version? I have moved the patch to next CF, waiting on
> > author for now.
>
> Rebased and updated patch is attached.
>
> There was a problem with testing new restore_command options altogether
> with recent ensureCleanShutdown. My test simply moves all WAL from
> pg_wal and generates restore_command for a new options testing, but this
> prevents startup recovery required by ensureCleanShutdown. To test both
> options in the same we have to leave some recent WAL segments in the
> pg_wal and be sure that they are enough for startup recovery, but not
> enough for successful pg_rewind run. I have manually figured out that
> required amount of inserted records (and generated WAL) to achieve this.
> However, I think that this approach is not good for test, since tests
> may be modified in the future (amount of writes to DB changed) or even
> volume of WAL written by Postgres will change. It will lead to falsely
> always failed or passed tests.
>
> Moreover, testing both ensureCleanShutdown and new options in the same
> time doesn't hit new code paths, so I decided to test new options with
> --no-ensure-shutdown for simplicity and stability of tests.

I think this patch is now in a good shape and already got enough of review.

I made some minor cleanup. In particular, I've to fix usage of terms
"WAL" and "WALs". This patch sometimes use term "WAL" to specify
single WAL file and term "WALs" to specify multiple WAL files. But
WAL stands for Write Ahead Log. So, "WALs" literally stands to
multiple logs. And we don't use term "WALs" to describe multiple WAL
files anywhere else. Usage of term "WAL" to describe single file is
not clear as well.

The revision of patch is attached. I'm going to push it if no objections.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Attachment Content-Type Size
v12-0001-pg_rewind-options-to-use-restore_command-from-co.patch application/octet-stream 24.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-01-18 16:05:53 Re: postgresql-13devel initDB Running in debug mode.
Previous Message Pavel Stehule 2020-01-18 15:19:24 Re: range_agg