Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Alexey Kondratov <a.kondratov@postgrespro.ru>
Cc: Alexander Korotkov <a.korotkov@postgrespro.ru>, Alvaro Herrera <alvherre@2ndquadrant.com>, Liudmila Mantrova <l.mantrova@postgrespro.ru>, Thomas Munro <thomas.munro@gmail.com>, Andrey Borodin <x4mmm@yandex-team.ru>, David Steele <david@pgmasters.net>, Andres Freund <andres@anarazel.de>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Dmitry Dolgov <9erthalion6@gmail.com>, vladimirlesk@yandex-team.ru, dsarafan@yandex-team.ru
Date: 2020-03-02T04:53:08Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Move frontend-side archive APIs from src/common/ to src/fe_utils/
- 8d8b89266ca0 13.0 landed
- a3b2bf1fe7ce 14.0 landed
-
Add -c/--restore-target-wal to pg_rewind
- a7e8ece41cf7 13.0 landed
-
Move routine definitions of xlogarchive.c to a new header file
- 616ae3d2b056 13.0 landed
-
Move routine building restore_command to src/common/
- e09ad07b21a2 13.0 landed
-
Integrate recovery.conf into postgresql.conf
- 2dedf4d9a899 12.0 cited
On Fri, Feb 28, 2020 at 03:37:47PM +0300, Alexey Kondratov wrote:
> I would prefer to keep it, since there are plenty of similar comments near
> Asserts and elogs all over the Postgres. Otherwise it may look like a valid
> error state. It may be obvious now, but for someone who is not aware of
> BuildRestoreCommand refactoring it may be not. So from my perspective there
> is nothing bad in this extra one line comment.
elog() is called in the event of errors which should never happen by
definition, so your comment is just a duplication of this state. I'd
still remove that.
> I have added explicit exit(1) calls, since pg_fatal was used only twice in
> the archive.c. Probably, pg_log_fatal from common/logging should obey the
> same logic as FATAL log-level in the backend and do exit the process, but
> for now including pg_rewind.h inside archive.c or vice versa does not look
> like a solution.
archive.c should not depend on anything from src/bin/.
> + * For fixed-size files, the caller may pass the expected size as an
> + * additional crosscheck on successful recovery. If the file size is not
> + * known, set expectedSize = 0.
> + */
> +int
> +RestoreArchivedWALFile(const char *path, const char *xlogfname,
> + off_t expectedSize, const char *restoreCommand)
Actually, expectedSize is IMO a bad idea, because any caller of this
routine passing down zero could be trapped with an incorrect file
size. So let's remove the behavior where it is possible to bypass
this sanity check. We don't need it in pg_rewind either.
> + if ((output_fp = popen(postgres_cmd, "r")) == NULL ||
> + fgets(cmd_output, sizeof(cmd_output), output_fp) == NULL)
> + pg_fatal("could not get restore_command using %s: %s",
> + postgres_cmd, strerror(errno));
Still missing one %m here.
> + /* Remove trailing newline */
> + if (strchr(cmd_output, '\n') != NULL)
> + *strchr(cmd_output, '\n') = '\0';
It seems to me that what you are looking here is to use
pg_strip_crlf(). Thinking harder, we have pipe_read_line() in
src/common/exec.c which does the exact same job..
> - /*
> - * construct the command to be executed
> - */
Perhaps you meant "build" here.
> + if (restore_wal)
> + {
> + int rc;
> + char postgres_exec_path[MAXPGPATH],
> + postgres_cmd[MAXPGPATH],
> + cmd_output[MAXPGPATH];
> + FILE *output_fp;
> +
> + /* Find postgres executable. */
> + rc = find_other_exec(argv[0], "postgres",
> + PG_BACKEND_VERSIONSTR,
> + postgres_exec_path);
For readability, I would move that into its own separate routine.
--
Michael