Re: [Patch] pg_rewind: options to use restore_command fromrecovery.conf or command line - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [Patch] pg_rewind: options to use restore_command fromrecovery.conf or command line
Date
Msg-id 20200304074555.GI2593@paquier.xyz
Whole thread Raw
In response to Re: [Patch] pg_rewind: options to use restore_command fromrecovery.conf or command line  (Alexey Kondratov <a.kondratov@postgrespro.ru>)
Responses Re: [Patch] pg_rewind: options to use restore_command fromrecovery.conf or command line
List pgsql-hackers
On Mon, Mar 02, 2020 at 08:59:49PM +0300, Alexey Kondratov wrote:
> OK, sounds reasonable, but just to be clear. I will remove only a
> possibility to bypass this sanity check (with 0), but leave expectedSize
> argument intact. We still need it, since pg_rewind takes WalSegSz from
> ControlFile and should pass it further, am I right?

We need to keep around the argument, but I think that we give any user
of this routine a favor by making mandatory a file size.

> pg_strip_crlf fits well, but would you mind if I also make pipe_read_line
> external in this patch?

I got to look at that more, and pipe_read_line() is a nice fit.

> Actually, the verb 'construct' is used historically applied to
> archive/restore commands (see also xlogarchive.c and pgarch.c), but it
> should be 'build' in (fe_)archive.c, since we have BuildRestoreCommand there
> now.
>
> All other remarks look clear for me, so I fix them in the next patch
> version, thanks.

Already done as per the attached, with a new routine named
getRestoreCommand() and more done.  There were a couple of extra
things I noticed on the way:
- Found some typos.
- The translation of pg_rewind --help was incorrect, with a sentence
cut in the middle (you used twice gettext).
- I did not actually get why you don't check for a missing command
when using wait_result_is_any_signal.  In this case I'd think that it
is better to exit immediately as follow-up calls would just fail.
- The code was rather careless about error handling and
RestoreArchivedWALFile(), and it seemed to me that it is rather
pointless to report an extra message "could not restore file \"%s\"
from archive" on top of the other error.
- I could not resist to add more documentation for the new routines of
src/common/..
- Used long options in the tests for readability, reworked the
comments.

On top of that, I have spent some time testing the reliability of the
test, and tested the whole on Windows and Linux.  This is in a rather
committable shape now.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: [HACKERS] WAL logging problem in 9.4.3?
Next
From: Prabhat Sahu
Date:
Subject: Re: [Proposal] Global temporary tables