pg_validatebackup -> pg_verifybackup?

Started by Robert Haasalmost 6 years ago29 messages
#1Robert Haas
robertmhaas@gmail.com
1 attachment(s)

Over at /messages/by-id/172c9d9b-1d0a-1b94-1456-376b1e017322@2ndquadrant.com
Peter Eisentraut suggests that pg_validatebackup should be called
pg_verifybackup, with corresponding terminology changes throughout the
code and documentation.

Here's a patch for that. I'd like to commit this quickly or abandon in
quickly, because large renaming patches like this are a pain to
maintain. I believe that there was a mild consensus in favor of this
on that thread, so I plan to go forward unless somebody shows up
pretty quickly to object.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Attachments:

0001-Rename-pg_validatebackup-to-pg_verifybackup.patchapplication/octet-stream; name=0001-Rename-pg_validatebackup-to-pg_verifybackup.patchDownload
From 31366a623ad488d1c1e3812010df017290e79b17 Mon Sep 17 00:00:00 2001
From: Robert Haas <rhaas@postgresql.org>
Date: Fri, 10 Apr 2020 11:03:28 -0400
Subject: [PATCH] Rename pg_validatebackup to pg_verifybackup.

Also, use "verify" rather than "validate" to refer to the process
being undertaken here. Per discussion, that is a more appropriate
term.

Discussion: https://www.postgresql.org/message-id/172c9d9b-1d0a-1b94-1456-376b1e017322@2ndquadrant.com
---
 doc/src/sgml/ref/allfiles.sgml                |  2 +-
 doc/src/sgml/ref/pg_basebackup.sgml           |  4 +-
 ...lidatebackup.sgml => pg_verifybackup.sgml} | 54 +++++------
 doc/src/sgml/reference.sgml                   |  2 +-
 src/bin/Makefile                              |  2 +-
 src/bin/pg_validatebackup/.gitignore          |  2 -
 src/bin/pg_verifybackup/.gitignore            |  2 +
 .../Makefile                                  | 18 ++--
 .../parse_manifest.c                          |  4 +-
 .../parse_manifest.h                          |  2 +-
 .../pg_verifybackup.c}                        | 96 +++++++++----------
 .../t/001_basic.pl                            | 18 ++--
 .../t/002_algorithm.pl                        | 10 +-
 .../t/003_corruption.pl                       | 14 +--
 .../t/004_options.pl                          | 28 +++---
 .../t/005_bad_manifest.pl                     |  4 +-
 .../t/006_encoding.pl                         |  6 +-
 .../t/007_wal.pl                              | 14 +--
 18 files changed, 141 insertions(+), 141 deletions(-)
 rename doc/src/sgml/ref/{pg_validatebackup.sgml => pg_verifybackup.sgml} (83%)
 delete mode 100644 src/bin/pg_validatebackup/.gitignore
 create mode 100644 src/bin/pg_verifybackup/.gitignore
 rename src/bin/{pg_validatebackup => pg_verifybackup}/Makefile (53%)
 rename src/bin/{pg_validatebackup => pg_verifybackup}/parse_manifest.c (99%)
 rename src/bin/{pg_validatebackup => pg_verifybackup}/parse_manifest.h (96%)
 rename src/bin/{pg_validatebackup/pg_validatebackup.c => pg_verifybackup/pg_verifybackup.c} (89%)
 rename src/bin/{pg_validatebackup => pg_verifybackup}/t/001_basic.pl (55%)
 rename src/bin/{pg_validatebackup => pg_verifybackup}/t/002_algorithm.pl (85%)
 rename src/bin/{pg_validatebackup => pg_verifybackup}/t/003_corruption.pl (94%)
 rename src/bin/{pg_validatebackup => pg_verifybackup}/t/004_options.pl (74%)
 rename src/bin/{pg_validatebackup => pg_verifybackup}/t/005_bad_manifest.pl (97%)
 rename src/bin/{pg_validatebackup => pg_verifybackup}/t/006_encoding.pl (79%)
 rename src/bin/{pg_validatebackup => pg_verifybackup}/t/007_wal.pl (81%)

diff --git a/doc/src/sgml/ref/allfiles.sgml b/doc/src/sgml/ref/allfiles.sgml
index ab71176cdf..0f0064150c 100644
--- a/doc/src/sgml/ref/allfiles.sgml
+++ b/doc/src/sgml/ref/allfiles.sgml
@@ -211,7 +211,7 @@ Complete list of usable sgml source files in this directory.
 <!ENTITY pgResetwal         SYSTEM "pg_resetwal.sgml">
 <!ENTITY pgRestore          SYSTEM "pg_restore.sgml">
 <!ENTITY pgRewind           SYSTEM "pg_rewind.sgml">
-<!ENTITY pgValidateBackup   SYSTEM "pg_validatebackup.sgml">
+<!ENTITY pgVerifyBackup     SYSTEM "pg_verifybackup.sgml">
 <!ENTITY pgtestfsync        SYSTEM "pgtestfsync.sgml">
 <!ENTITY pgtesttiming       SYSTEM "pgtesttiming.sgml">
 <!ENTITY pgupgrade          SYSTEM "pgupgrade.sgml">
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index d9c981cebb..01ce44ee22 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
+++ b/doc/src/sgml/ref/pg_basebackup.sgml
@@ -568,7 +568,7 @@ PostgreSQL documentation
        <para>
         Disables generation of a backup manifest. If this option is not
         specified, the server will generate and send a backup manifest
-        which can be verified using <xref linkend="app-pgvalidatebackup" />.
+        which can be verified using <xref linkend="app-pgverifybackup" />.
         The manifest is a list of every file present in the backup with the
         exception of any WAL files that may be included. It also stores the
         size, last modification time, and an optional checksum for each file.
@@ -620,7 +620,7 @@ PostgreSQL documentation
         verified not to have been modified since the backup was taken.
        </para>
        <para>
-        <xref linkend="app-pgvalidatebackup" /> can be used to check the
+        <xref linkend="app-pgverifybackup" /> can be used to check the
         integrity of a backup against the backup manifest.
        </para>
       </listitem>
diff --git a/doc/src/sgml/ref/pg_validatebackup.sgml b/doc/src/sgml/ref/pg_verifybackup.sgml
similarity index 83%
rename from doc/src/sgml/ref/pg_validatebackup.sgml
rename to doc/src/sgml/ref/pg_verifybackup.sgml
index 19888dc196..64a1d92105 100644
--- a/doc/src/sgml/ref/pg_validatebackup.sgml
+++ b/doc/src/sgml/ref/pg_verifybackup.sgml
@@ -1,28 +1,28 @@
 <!--
-doc/src/sgml/ref/pg_validatebackup.sgml
+doc/src/sgml/ref/pg_verifybackup.sgml
 PostgreSQL documentation
 -->
 
-<refentry id="app-pgvalidatebackup">
- <indexterm zone="app-pgvalidatebackup">
-  <primary>pg_validatebackup</primary>
+<refentry id="app-pgverifybackup">
+ <indexterm zone="app-pgverifybackup">
+  <primary>pg_verifybackup</primary>
  </indexterm>
 
  <refmeta>
-  <refentrytitle>pg_validatebackup</refentrytitle>
+  <refentrytitle>pg_verifybackup</refentrytitle>
   <manvolnum>1</manvolnum>
   <refmiscinfo>Application</refmiscinfo>
  </refmeta>
 
  <refnamediv>
-  <refname>pg_validatebackup</refname>
+  <refname>pg_verifybackup</refname>
   <refpurpose>verify the integrity of a base backup of a
   <productname>PostgreSQL</productname> cluster</refpurpose>
  </refnamediv>
 
  <refsynopsisdiv>
   <cmdsynopsis>
-   <command>pg_validatebackup</command>
+   <command>pg_verifybackup</command>
    <arg rep="repeat"><replaceable>option</replaceable></arg>
   </cmdsynopsis>
  </refsynopsisdiv>
@@ -32,7 +32,7 @@ PostgreSQL documentation
    Description
   </title>
   <para>
-   <application>pg_validatebackup</application> is used to check the
+   <application>pg_verifybackup</application> is used to check the
    integrity of a database cluster backup taken using
    <command>pg_basebackup</command> against a
    <literal>backup_manifest</literal> generated by the server at the time
@@ -42,26 +42,26 @@ PostgreSQL documentation
 
   <para>
    It is important to note that that the validation which is performed by
-   <application>pg_validatebackup</application> does not and can not include
+   <application>pg_verifybackup</application> does not and can not include
    every check which will be performed by a running server when attempting
    to make use of the backup. Even if you use this tool, you should still
    perform test restores and verify that the resulting databases work as
    expected and that they appear to contain the correct data. However,
-   <application>pg_validatebackup</application> can detect many problems
+   <application>pg_verifybackup</application> can detect many problems
    that commonly occur due to storage problems or user error.
   </para>
 
   <para>
    Backup verification proceeds in four stages. First,
-   <literal>pg_validatebackup</literal> reads the
+   <literal>pg_verifybackup</literal> reads the
    <literal>backup_manifest</literal> file. If that file
    does not exist, cannot be read, is malformed, or fails verification
-   against its own internal checksum, <literal>pg_validatebackup</literal>
+   against its own internal checksum, <literal>pg_verifybackup</literal>
    will terminate with a fatal error.
   </para>
 
   <para>
-   Second, <literal>pg_validatebackup</literal> will attempt to verify that
+   Second, <literal>pg_verifybackup</literal> will attempt to verify that
    the data files currently stored on disk are exactly the same as the data
    files which the server intended to send, with some exceptions that are
    described below. Extra and missing files will be detected, with a few
@@ -79,7 +79,7 @@ PostgreSQL documentation
   </para>
 
   <para>
-   Next, <literal>pg_validatebackup</literal> will checksum all the files,
+   Next, <literal>pg_verifybackup</literal> will checksum all the files,
    compare the checksums against the values in the manifest, and emit errors
    for any files for which the computed checksum does not match the
    checksum stored in the manifest. This step is not performed for any files
@@ -89,12 +89,12 @@ PostgreSQL documentation
   </para>
 
   <para>
-   Finally, <literal>pg_validatebackup</literal> will use the manifest to
+   Finally, <literal>pg_verifybackup</literal> will use the manifest to
    verify that the write-ahead log records which will be needed to recover
    the backup are present and that they can be read and parsed. The
    <literal>backup_manifest</literal> contains information about which
    write-ahead log records will be needed, and
-   <literal>pg_validatebackup</literal> will use that information to
+   <literal>pg_verifybackup</literal> will use that information to
    invoke <literal>pg_waldump</literal> to parse those write-ahed log
    records. The <literal>--quiet</literal> flag will be used, so that
    <literal>pg_waldump</literal> will only report errors, without producing
@@ -112,7 +112,7 @@ PostgreSQL documentation
    are present, they will not be checked by this tool, although
    a separate invocation of <literal>pg_waldump</literal> could be used for
    that purpose. Also note that WAL verification is version-specific: you
-   must use the version of <literal>pg_validatebackup</literal>, and thus of
+   must use the version of <literal>pg_verifybackup</literal>, and thus of
    <literal>pg_waldump</literal>, which pertains to the backup being checked.
    In contrast, the data file integrity checks should work with any version
    of the server that generates a <literal>backup_manifest</literal> file.
@@ -184,7 +184,7 @@ PostgreSQL documentation
       <term><option>--quiet</option></term>
       <listitem>
        <para>
-        Don't print anything when a backup is successfully validated.
+        Don't print anything when a backup is successfully verified.
        </para>
       </listitem>
      </varlistentry>
@@ -194,7 +194,7 @@ PostgreSQL documentation
       <term><option>--skip-checksums</option></term>
       <listitem>
        <para>
-        Do not validate data file checksums. The presence or absence of
+        Do not verify data file checksums. The presence or absence of
         files and the sizes of those files will still be checked. This is
         much faster, because the files themselves do not need to be read.
        </para>
@@ -224,7 +224,7 @@ PostgreSQL documentation
        <term><option>--version</option></term>
        <listitem>
        <para>
-       Print the <application>pg_validatebackup</application> version and exit.
+       Print the <application>pg_verifybackup</application> version and exit.
        </para>
        </listitem>
      </varlistentry>
@@ -234,7 +234,7 @@ PostgreSQL documentation
        <term><option>--help</option></term>
        <listitem>
        <para>
-       Show help about <application>pg_validatebackup</application> command
+       Show help about <application>pg_verifybackup</application> command
        line arguments, and exit.
        </para>
        </listitem>
@@ -250,31 +250,31 @@ PostgreSQL documentation
 
   <para>
    To create a base backup of the server at <literal>mydbserver</literal> and
-   validate the integrity of the backup:
+   verify the integrity of the backup:
 <screen>
 <prompt>$</prompt> <userinput>pg_basebackup -h mydbserver -D /usr/local/pgsql/data</userinput>
-<prompt>$</prompt> <userinput>pg_validatebackup /usr/local/pgsql/data</userinput>
+<prompt>$</prompt> <userinput>pg_verifybackup /usr/local/pgsql/data</userinput>
 </screen>
   </para>
 
   <para>
    To create a base backup of the server at <literal>mydbserver</literal>, move
-   the manifest somewhere outside the backup directory, and validate the
+   the manifest somewhere outside the backup directory, and verify the
    backup:
 <screen>
 <prompt>$</prompt> <userinput>pg_basebackup -h mydbserver -D /usr/local/pgsql/backup1234</userinput>
 <prompt>$</prompt> <userinput>mv /usr/local/pgsql/backup1234/backup_manifest /my/secure/location/backup_manifest.1234</userinput>
-<prompt>$</prompt> <userinput>pg_validatebackup -m /my/secure/location/backup_manifest.1234 /usr/local/pgsql/backup1234</userinput>
+<prompt>$</prompt> <userinput>pg_verifybackup -m /my/secure/location/backup_manifest.1234 /usr/local/pgsql/backup1234</userinput>
 </screen>
   </para>
 
   <para>
-   To validate a backup while ignoring a file that was added manually to the
+   To verify a backup while ignoring a file that was added manually to the
    backup directory, and also skipping checksum verification:
 <screen>
 <prompt>$</prompt> <userinput>pg_basebackup -h mydbserver -D /usr/local/pgsql/data</userinput>
 <prompt>$</prompt> <userinput>edit /usr/local/pgsql/data/note.to.self</userinput>
-<prompt>$</prompt> <userinput>pg_validatebackup --ignore=note.to.self --skip-checksums /usr/local/pgsql/data</userinput>
+<prompt>$</prompt> <userinput>pg_verifybackup --ignore=note.to.self --skip-checksums /usr/local/pgsql/data</userinput>
 </screen>
   </para>
 
diff --git a/doc/src/sgml/reference.sgml b/doc/src/sgml/reference.sgml
index d25a77b13c..dd2bddab8c 100644
--- a/doc/src/sgml/reference.sgml
+++ b/doc/src/sgml/reference.sgml
@@ -255,7 +255,7 @@
    &pgReceivewal;
    &pgRecvlogical;
    &pgRestore;
-   &pgValidateBackup;
+   &pgVerifyBackup;
    &psqlRef;
    &reindexdb;
    &vacuumdb;
diff --git a/src/bin/Makefile b/src/bin/Makefile
index 77bceea4fe..8b870357a1 100644
--- a/src/bin/Makefile
+++ b/src/bin/Makefile
@@ -27,7 +27,7 @@ SUBDIRS = \
 	pg_test_fsync \
 	pg_test_timing \
 	pg_upgrade \
-	pg_validatebackup \
+	pg_verifybackup \
 	pg_waldump \
 	pgbench \
 	psql \
diff --git a/src/bin/pg_validatebackup/.gitignore b/src/bin/pg_validatebackup/.gitignore
deleted file mode 100644
index 21e0a92429..0000000000
--- a/src/bin/pg_validatebackup/.gitignore
+++ /dev/null
@@ -1,2 +0,0 @@
-/pg_validatebackup
-/tmp_check/
diff --git a/src/bin/pg_verifybackup/.gitignore b/src/bin/pg_verifybackup/.gitignore
new file mode 100644
index 0000000000..910b227ce9
--- /dev/null
+++ b/src/bin/pg_verifybackup/.gitignore
@@ -0,0 +1,2 @@
+/pg_verifybackup
+/tmp_check/
diff --git a/src/bin/pg_validatebackup/Makefile b/src/bin/pg_verifybackup/Makefile
similarity index 53%
rename from src/bin/pg_validatebackup/Makefile
rename to src/bin/pg_verifybackup/Makefile
index b1c2b7c1be..c07643b129 100644
--- a/src/bin/pg_validatebackup/Makefile
+++ b/src/bin/pg_verifybackup/Makefile
@@ -1,9 +1,9 @@
-# src/bin/pg_validatebackup/Makefile
+# src/bin/pg_verifybackup/Makefile
 
-PGFILEDESC = "pg_validatebackup - validate a backup against a backup manifest"
+PGFILEDESC = "pg_verifybackup - verify a backup against using a backup manifest"
 PGAPPICON = win32
 
-subdir = src/bin/pg_validatebackup
+subdir = src/bin/pg_verifybackup
 top_builddir = ../../..
 include $(top_builddir)/src/Makefile.global
 
@@ -13,24 +13,24 @@ LDFLAGS_INTERNAL += -L$(top_builddir)/src/fe_utils -lpgfeutils $(libpq_pgport)
 OBJS = \
 	$(WIN32RES) \
 	parse_manifest.o \
-	pg_validatebackup.o
+	pg_verifybackup.o
 
-all: pg_validatebackup
+all: pg_verifybackup
 
-pg_validatebackup: $(OBJS) | submake-libpq submake-libpgport submake-libpgfeutils
+pg_verifybackup: $(OBJS) | submake-libpq submake-libpgport submake-libpgfeutils
 	$(CC) $(CFLAGS) $^ $(LDFLAGS) $(LDFLAGS_EX) $(LIBS) -o $@$(X)
 
 install: all installdirs
-	$(INSTALL_PROGRAM) pg_validatebackup$(X) '$(DESTDIR)$(bindir)/pg_validatebackup$(X)'
+	$(INSTALL_PROGRAM) pg_verifybackup$(X) '$(DESTDIR)$(bindir)/pg_verifybackup$(X)'
 
 installdirs:
 	$(MKDIR_P) '$(DESTDIR)$(bindir)'
 
 uninstall:
-	rm -f '$(DESTDIR)$(bindir)/pg_validatebackup$(X)'
+	rm -f '$(DESTDIR)$(bindir)/pg_verifybackup$(X)'
 
 clean distclean maintainer-clean:
-	rm -f pg_validatebackup$(X) $(OBJS)
+	rm -f pg_verifybackup$(X) $(OBJS)
 	rm -rf tmp_check
 
 check:
diff --git a/src/bin/pg_validatebackup/parse_manifest.c b/src/bin/pg_verifybackup/parse_manifest.c
similarity index 99%
rename from src/bin/pg_validatebackup/parse_manifest.c
rename to src/bin/pg_verifybackup/parse_manifest.c
index 0ec9dd6a13..faee423c7e 100644
--- a/src/bin/pg_validatebackup/parse_manifest.c
+++ b/src/bin/pg_verifybackup/parse_manifest.c
@@ -6,7 +6,7 @@
  * Portions Copyright (c) 1996-2020, PostgreSQL Global Development Group
  * Portions Copyright (c) 1994, Regents of the University of California
  *
- * src/bin/pg_validatebackup/parse_manifest.c
+ * src/bin/pg_verifybackup/parse_manifest.c
  *
  *-------------------------------------------------------------------------
  */
@@ -151,7 +151,7 @@ json_parse_manifest(JsonManifestParseContext *context, char *buffer,
 	if (parse.state != JM_EXPECT_EOF)
 		json_manifest_parse_failure(context, "manifest ended unexpectedly");
 
-	/* Validate the checksum. */
+	/* Verify the manifest checksum. */
 	verify_manifest_checksum(&parse, buffer, size);
 }
 
diff --git a/src/bin/pg_validatebackup/parse_manifest.h b/src/bin/pg_verifybackup/parse_manifest.h
similarity index 96%
rename from src/bin/pg_validatebackup/parse_manifest.h
rename to src/bin/pg_verifybackup/parse_manifest.h
index f0a4fac36b..49254bfb32 100644
--- a/src/bin/pg_validatebackup/parse_manifest.h
+++ b/src/bin/pg_verifybackup/parse_manifest.h
@@ -6,7 +6,7 @@
  * Portions Copyright (c) 1996-2020, PostgreSQL Global Development Group
  * Portions Copyright (c) 1994, Regents of the University of California
  *
- * src/bin/pg_validatebackup/parse_manifest.h
+ * src/bin/pg_verifybackup/parse_manifest.h
  *
  *-------------------------------------------------------------------------
  */
diff --git a/src/bin/pg_validatebackup/pg_validatebackup.c b/src/bin/pg_verifybackup/pg_verifybackup.c
similarity index 89%
rename from src/bin/pg_validatebackup/pg_validatebackup.c
rename to src/bin/pg_verifybackup/pg_verifybackup.c
index f274638500..9c0a8c5550 100644
--- a/src/bin/pg_validatebackup/pg_validatebackup.c
+++ b/src/bin/pg_verifybackup/pg_verifybackup.c
@@ -1,12 +1,12 @@
 /*-------------------------------------------------------------------------
  *
- * pg_validatebackup.c
- *	  Validate a backup against a backup manifest.
+ * pg_verifybackup.c
+ *	  Verify a backup against a backup manifest.
  *
  * Portions Copyright (c) 1996-2020, PostgreSQL Global Development Group
  * Portions Copyright (c) 1994, Regents of the University of California
  *
- * src/bin/pg_validatebackup/pg_validatebackup.c
+ * src/bin/pg_verifybackup/pg_verifybackup.c
  *
  *-------------------------------------------------------------------------
  */
@@ -101,14 +101,14 @@ typedef struct parser_context
 /*
  * All of the context information we need while checking a backup manifest.
  */
-typedef struct validator_context
+typedef struct verifier_context
 {
 	manifest_files_hash *ht;
 	char	   *backup_directory;
 	SimpleStringList ignore_list;
 	bool		exit_on_error;
 	bool		saw_any_error;
-} validator_context;
+} verifier_context;
 
 static void parse_manifest_file(char *manifest_path,
 								manifest_files_hash **ht_p,
@@ -127,25 +127,25 @@ static void report_manifest_error(JsonManifestParseContext *context,
 								  char *fmt,...)
 			pg_attribute_printf(2, 3) pg_attribute_noreturn();
 
-static void validate_backup_directory(validator_context *context,
-									  char *relpath, char *fullpath);
-static void validate_backup_file(validator_context *context,
-								 char *relpath, char *fullpath);
-static void report_extra_backup_files(validator_context *context);
-static void validate_backup_checksums(validator_context *context);
-static void validate_file_checksum(validator_context *context,
-								   manifest_file *m, char *pathname);
-static void parse_required_wal(validator_context *context,
+static void verify_backup_directory(verifier_context *context,
+									char *relpath, char *fullpath);
+static void verify_backup_file(verifier_context *context,
+							   char *relpath, char *fullpath);
+static void report_extra_backup_files(verifier_context *context);
+static void verify_backup_checksums(verifier_context *context);
+static void verify_file_checksum(verifier_context *context,
+								 manifest_file *m, char *pathname);
+static void parse_required_wal(verifier_context *context,
 							   char *pg_waldump_path,
 							   char *wal_directory,
 							   manifest_wal_range *first_wal_range);
 
-static void report_backup_error(validator_context *context,
+static void report_backup_error(verifier_context *context,
 								const char *pg_restrict fmt,...)
 			pg_attribute_printf(2, 3);
 static void report_fatal_error(const char *pg_restrict fmt,...)
 			pg_attribute_printf(1, 2) pg_attribute_noreturn();
-static bool should_ignore_relpath(validator_context *context, char *relpath);
+static bool should_ignore_relpath(verifier_context *context, char *relpath);
 
 static void usage(void);
 
@@ -170,7 +170,7 @@ main(int argc, char **argv)
 	};
 
 	int			c;
-	validator_context context;
+	verifier_context context;
 	manifest_wal_range *first_wal_range;
 	char	   *manifest_path = NULL;
 	bool		no_parse_wal = false;
@@ -180,7 +180,7 @@ main(int argc, char **argv)
 	char	   *pg_waldump_path = NULL;
 
 	pg_logging_init(argv[0]);
-	set_pglocale_pgservice(argv[0], PG_TEXTDOMAIN("pg_validatebackup"));
+	set_pglocale_pgservice(argv[0], PG_TEXTDOMAIN("pg_verifybackup"));
 	progname = get_progname(argv[0]);
 
 	memset(&context, 0, sizeof(context));
@@ -194,7 +194,7 @@ main(int argc, char **argv)
 		}
 		if (strcmp(argv[1], "--version") == 0 || strcmp(argv[1], "-V") == 0)
 		{
-			puts("pg_validatebackup (PostgreSQL) " PG_VERSION);
+			puts("pg_verifybackup (PostgreSQL) " PG_VERSION);
 			exit(0);
 		}
 	}
@@ -207,7 +207,7 @@ main(int argc, char **argv)
 	 *
 	 * Ignore the pg_wal directory, because those files are not included in
 	 * the backup manifest either, since they are fetched separately from the
-	 * backup itself, and validated via a separate mechanism.
+	 * backup itself, and verified via a separate mechanism.
 	 *
 	 * Ignore postgresql.auto.conf, recovery.signal, and standby.signal,
 	 * because we expect that those files may sometimes be created or changed
@@ -299,12 +299,12 @@ main(int argc, char **argv)
 				pg_log_fatal("The program \"%s\" is needed by %s but was\n"
 							 "not found in the same directory as \"%s\".\n"
 							 "Check your installation.",
-							 "pg_waldump", "pg_validatebackup", full_path);
+							 "pg_waldump", "pg_verifybackup", full_path);
 			else
 				pg_log_fatal("The program \"%s\" was found by \"%s\" but was\n"
 							 "not the same version as %s.\n"
 							 "Check your installation.",
-							 "pg_waldump", full_path, "pg_validatebackup");
+							 "pg_waldump", full_path, "pg_verifybackup");
 		}
 	}
 
@@ -320,7 +320,7 @@ main(int argc, char **argv)
 	/*
 	 * Try to read the manifest. We treat any errors encountered while parsing
 	 * the manifest as fatal; there doesn't seem to be much point in trying to
-	 * validate the backup directory against a corrupted manifest.
+	 * verify the backup directory against a corrupted manifest.
 	 */
 	parse_manifest_file(manifest_path, &context.ht, &first_wal_range);
 
@@ -330,7 +330,7 @@ main(int argc, char **argv)
 	 * match. We also set the "matched" flag on every manifest entry that
 	 * corresponds to a file on disk.
 	 */
-	validate_backup_directory(&context, NULL, context.backup_directory);
+	verify_backup_directory(&context, NULL, context.backup_directory);
 
 	/*
 	 * The "matched" flag should now be set on every entry in the hash table.
@@ -344,7 +344,7 @@ main(int argc, char **argv)
 	 * told to skip it.
 	 */
 	if (!skip_checksums)
-		validate_backup_checksums(&context);
+		verify_backup_checksums(&context);
 
 	/*
 	 * Try to parse the required ranges of WAL records, unless we were told
@@ -512,17 +512,17 @@ record_manifest_details_for_wal_range(JsonManifestParseContext *context,
 }
 
 /*
- * Validate one directory.
+ * Verify one directory.
  *
- * 'relpath' is NULL if we are to validate the top-level backup directory,
- * and otherwise the relative path to the directory that is to be validated.
+ * 'relpath' is NULL if we are to verify the top-level backup directory,
+ * and otherwise the relative path to the directory that is to be verified.
  *
  * 'fullpath' is the backup directory with 'relpath' appended; i.e. the actual
  * filesystem path at which it can be found.
  */
 static void
-validate_backup_directory(validator_context *context, char *relpath,
-						  char *fullpath)
+verify_backup_directory(verifier_context *context, char *relpath,
+						char *fullpath)
 {
 	DIR		   *dir;
 	struct dirent *dirent;
@@ -565,7 +565,7 @@ validate_backup_directory(validator_context *context, char *relpath,
 			newrelpath = psprintf("%s/%s", relpath, filename);
 
 		if (!should_ignore_relpath(context, newrelpath))
-			validate_backup_file(context, newrelpath, newfullpath);
+			verify_backup_file(context, newrelpath, newfullpath);
 
 		pfree(newfullpath);
 		pfree(newrelpath);
@@ -580,13 +580,13 @@ validate_backup_directory(validator_context *context, char *relpath,
 }
 
 /*
- * Validate one file (which might actually be a directory or a symlink).
+ * Verify one file (which might actually be a directory or a symlink).
  *
  * The arguments to this function have the same meaning as the arguments to
- * validate_backup_directory.
+ * verify_backup_directory.
  */
 static void
-validate_backup_file(validator_context *context, char *relpath, char *fullpath)
+verify_backup_file(verifier_context *context, char *relpath, char *fullpath)
 {
 	struct stat sb;
 	manifest_file *m;
@@ -609,7 +609,7 @@ validate_backup_file(validator_context *context, char *relpath, char *fullpath)
 	/* If it's a directory, just recurse. */
 	if (S_ISDIR(sb.st_mode))
 	{
-		validate_backup_directory(context, relpath, fullpath);
+		verify_backup_directory(context, relpath, fullpath);
 		return;
 	}
 
@@ -645,7 +645,7 @@ validate_backup_file(validator_context *context, char *relpath, char *fullpath)
 	}
 
 	/*
-	 * We don't validate checksums at this stage. We first finish validating
+	 * We don't verify checksums at this stage. We first finish verifying
 	 * that we have the expected set of files with the expected sizes, and
 	 * only afterwards verify the checksums. That's because computing
 	 * checksums may take a while, and we'd like to report more obvious
@@ -658,7 +658,7 @@ validate_backup_file(validator_context *context, char *relpath, char *fullpath)
  * that such files are present in the manifest but not on disk.
  */
 static void
-report_extra_backup_files(validator_context *context)
+report_extra_backup_files(verifier_context *context)
 {
 	manifest_files_iterator it;
 	manifest_file *m;
@@ -672,12 +672,12 @@ report_extra_backup_files(validator_context *context)
 }
 
 /*
- * Validate checksums for hash table entries that are otherwise unproblematic.
+ * Verify checksums for hash table entries that are otherwise unproblematic.
  * If we've already reported some problem related to a hash table entry, or
  * if it has no checksum, just skip it.
  */
 static void
-validate_backup_checksums(validator_context *context)
+verify_backup_checksums(verifier_context *context)
 {
 	manifest_files_iterator it;
 	manifest_file *m;
@@ -694,8 +694,8 @@ validate_backup_checksums(validator_context *context)
 			fullpath = psprintf("%s/%s", context->backup_directory,
 								m->pathname);
 
-			/* Do the actual checksum validation. */
-			validate_file_checksum(context, m, fullpath);
+			/* Do the actual checksum verification. */
+			verify_file_checksum(context, m, fullpath);
 
 			/* Avoid leaking memory. */
 			pfree(fullpath);
@@ -704,10 +704,10 @@ validate_backup_checksums(validator_context *context)
 }
 
 /*
- * Validate the checksum of a single file.
+ * Verify the checksum of a single file.
  */
 static void
-validate_file_checksum(validator_context *context, manifest_file *m,
+verify_file_checksum(verifier_context *context, manifest_file *m,
 					   char *fullpath)
 {
 	pg_checksum_context checksum_ctx;
@@ -754,7 +754,7 @@ validate_file_checksum(validator_context *context, manifest_file *m,
 
 	/*
 	 * Double-check that we read the expected number of bytes from the file.
-	 * Normally, a file size mismatch would be caught in validate_backup_file
+	 * Normally, a file size mismatch would be caught in verify_backup_file
 	 * and this check would never be reached, but this provides additional
 	 * safety and clarity in the event of concurrent modifications or
 	 * filesystem misbehavior.
@@ -786,7 +786,7 @@ validate_file_checksum(validator_context *context, manifest_file *m,
  * pg_waldump.
  */
 static void
-parse_required_wal(validator_context *context, char *pg_waldump_path,
+parse_required_wal(verifier_context *context, char *pg_waldump_path,
 				   char *wal_directory, manifest_wal_range *first_wal_range)
 {
 	manifest_wal_range *this_wal_range = first_wal_range;
@@ -817,7 +817,7 @@ parse_required_wal(validator_context *context, char *pg_waldump_path,
  * context says we should.
  */
 static void
-report_backup_error(validator_context *context, const char *pg_restrict fmt,...)
+report_backup_error(verifier_context *context, const char *pg_restrict fmt,...)
 {
 	va_list		ap;
 
@@ -853,7 +853,7 @@ report_fatal_error(const char *pg_restrict fmt,...)
  * "aa/bb" is not a prefix of "aa/bbb", but it is a prefix of "aa/bb/cc".
  */
 static bool
-should_ignore_relpath(validator_context *context, char *relpath)
+should_ignore_relpath(verifier_context *context, char *relpath)
 {
 	SimpleStringListCell *cell;
 
@@ -889,7 +889,7 @@ hash_string_pointer(char *s)
 static void
 usage(void)
 {
-	printf(_("%s validates a backup against the backup manifest.\n\n"), progname);
+	printf(_("%s verifies a backup against the backup manifest.\n\n"), progname);
 	printf(_("Usage:\n  %s [OPTION]... BACKUPDIR\n\n"), progname);
 	printf(_("Options:\n"));
 	printf(_("  -e, --exit-on-error         exit immediately on error\n"));
diff --git a/src/bin/pg_validatebackup/t/001_basic.pl b/src/bin/pg_verifybackup/t/001_basic.pl
similarity index 55%
rename from src/bin/pg_validatebackup/t/001_basic.pl
rename to src/bin/pg_verifybackup/t/001_basic.pl
index 6d4b8ea01a..0d4d71aaa1 100644
--- a/src/bin/pg_validatebackup/t/001_basic.pl
+++ b/src/bin/pg_verifybackup/t/001_basic.pl
@@ -5,17 +5,17 @@ use Test::More tests => 16;
 
 my $tempdir = TestLib::tempdir;
 
-program_help_ok('pg_validatebackup');
-program_version_ok('pg_validatebackup');
-program_options_handling_ok('pg_validatebackup');
+program_help_ok('pg_verifybackup');
+program_version_ok('pg_verifybackup');
+program_options_handling_ok('pg_verifybackup');
 
-command_fails_like(['pg_validatebackup'],
+command_fails_like(['pg_verifybackup'],
 				   qr/no backup directory specified/,
 				   'target directory must be specified');
-command_fails_like(['pg_validatebackup', $tempdir],
+command_fails_like(['pg_verifybackup', $tempdir],
 				   qr/could not open file.*\/backup_manifest\"/,
-				   'pg_validatebackup requires a manifest');
-command_fails_like(['pg_validatebackup', $tempdir, $tempdir],
+				   'pg_verifybackup requires a manifest');
+command_fails_like(['pg_verifybackup', $tempdir, $tempdir],
 				   qr/too many command-line arguments/,
 				   'multiple target directories not allowed');
 
@@ -24,7 +24,7 @@ open(my $fh, '>', "$tempdir/backup_manifest") || die "open: $!";
 close($fh);
 
 # but then try to use an alternate, nonexisting manifest
-command_fails_like(['pg_validatebackup', '-m', "$tempdir/not_the_manifest",
+command_fails_like(['pg_verifybackup', '-m', "$tempdir/not_the_manifest",
 						$tempdir],
 				   qr/could not open file.*\/not_the_manifest\"/,
-				   'pg_validatebackup respects -m flag');
+				   'pg_verifybackup respects -m flag');
diff --git a/src/bin/pg_validatebackup/t/002_algorithm.pl b/src/bin/pg_verifybackup/t/002_algorithm.pl
similarity index 85%
rename from src/bin/pg_validatebackup/t/002_algorithm.pl
rename to src/bin/pg_verifybackup/t/002_algorithm.pl
index 98871e12a5..ee82dcee37 100644
--- a/src/bin/pg_validatebackup/t/002_algorithm.pl
+++ b/src/bin/pg_verifybackup/t/002_algorithm.pl
@@ -1,4 +1,4 @@
-# Verify that we can take and validate backups with various checksum types.
+# Verify that we can take and verify backups with various checksum types.
 
 use strict;
 use warnings;
@@ -19,7 +19,7 @@ for my $algorithm (qw(bogus none crc32c sha224 sha256 sha384 sha512))
 	my @backup = ('pg_basebackup', '-D', $backup_path,
 				  '--manifest-checksums', $algorithm,
 				  '--no-sync');
-	my @validate = ('pg_validatebackup', '-e', $backup_path);
+	my @verify = ('pg_verifybackup', '-e', $backup_path);
 
 	# A backup with a bogus algorithm should fail.
 	if ($algorithm eq 'bogus')
@@ -49,9 +49,9 @@ for my $algorithm (qw(bogus none crc32c sha224 sha256 sha384 sha512))
 			   "$algorithm is mentioned many times in the manifest");
 	}
 
-	# Make sure that it validates OK.
-	$master->command_ok(\@validate,
-						"validate backup with algorithm \"$algorithm\"");
+	# Make sure that it verifies OK.
+	$master->command_ok(\@verify,
+						"verify backup with algorithm \"$algorithm\"");
 
 	# Remove backup immediately to save disk space.
 	rmtree($backup_path);
diff --git a/src/bin/pg_validatebackup/t/003_corruption.pl b/src/bin/pg_verifybackup/t/003_corruption.pl
similarity index 94%
rename from src/bin/pg_validatebackup/t/003_corruption.pl
rename to src/bin/pg_verifybackup/t/003_corruption.pl
index 7a09d02e6c..a34e260739 100644
--- a/src/bin/pg_validatebackup/t/003_corruption.pl
+++ b/src/bin/pg_verifybackup/t/003_corruption.pl
@@ -1,4 +1,4 @@
-# Verify that various forms of corruption are detected by pg_validatebackup.
+# Verify that various forms of corruption are detected by pg_verifybackup.
 
 use strict;
 use warnings;
@@ -102,22 +102,22 @@ for my $scenario (@scenario)
 		skip "unix-style permissions not supported on Windows", 4
 			if $scenario->{'skip_on_windows'} && $windows_os;
 
-		# Take a backup and check that it validates OK.
+		# Take a backup and check that it verifies OK.
 		my $backup_path = $master->backup_dir . '/' . $name;
 		my $backup_ts_path = TestLib::perl2host(TestLib::tempdir_short());
 		$master->command_ok(['pg_basebackup', '-D', $backup_path, '--no-sync',
 							'-T', "${source_ts_path}=${backup_ts_path}"],
 							"base backup ok");
-		command_ok(['pg_validatebackup', $backup_path ],
-				   "intact backup validated");
+		command_ok(['pg_verifybackup', $backup_path ],
+				   "intact backup verified");
 
 		# Mutilate the backup in some way.
 		$scenario->{'mutilate'}->($backup_path);
 
-		# Now check that the backup no longer validates.
-		command_fails_like(['pg_validatebackup', $backup_path ],
+		# Now check that the backup no longer verifies.
+		command_fails_like(['pg_verifybackup', $backup_path ],
 						   $scenario->{'fails_like'},
-						   "corrupt backup fails validation: $name");
+						   "corrupt backup fails verification: $name");
 
 		# Run cleanup hook, if provided.
 		$scenario->{'cleanup'}->($backup_path)
diff --git a/src/bin/pg_validatebackup/t/004_options.pl b/src/bin/pg_verifybackup/t/004_options.pl
similarity index 74%
rename from src/bin/pg_validatebackup/t/004_options.pl
rename to src/bin/pg_verifybackup/t/004_options.pl
index 8f185626ed..9bae8eb565 100644
--- a/src/bin/pg_validatebackup/t/004_options.pl
+++ b/src/bin/pg_verifybackup/t/004_options.pl
@@ -1,4 +1,4 @@
-# Verify the behavior of assorted pg_validatebackup options.
+# Verify the behavior of assorted pg_verifybackup options.
 
 use strict;
 use warnings;
@@ -17,10 +17,10 @@ my $backup_path = $master->backup_dir . '/test_options';
 $master->command_ok(['pg_basebackup', '-D', $backup_path, '--no-sync' ],
 					"base backup ok");
 
-# Verify that pg_validatebackup -q succeeds and produces no output.
+# Verify that pg_verifybackup -q succeeds and produces no output.
 my $stdout;
 my $stderr;
-my $result = IPC::Run::run ['pg_validatebackup', '-q', $backup_path ],
+my $result = IPC::Run::run ['pg_verifybackup', '-q', $backup_path ],
 	'>', \$stdout, '2>', \$stderr;
 ok($result, "-q succeeds: exit code 0");
 is($stdout, '', "-q succeeds: no stdout");
@@ -33,19 +33,19 @@ open(my $fh, '>', $version_pathname) || die "open $version_pathname: $!";
 print $fh 'q' x length($version_contents);
 close($fh);
 
-# Verify that pg_validatebackup -q now fails.
-command_fails_like(['pg_validatebackup', '-q', $backup_path ],
+# Verify that pg_verifybackup -q now fails.
+command_fails_like(['pg_verifybackup', '-q', $backup_path ],
 				   qr/checksum mismatch for file \"PG_VERSION\"/,
 				   '-q checksum mismatch');
 
-# Since we didn't change the length of the file, validation should succeed
+# Since we didn't change the length of the file, verification should succeed
 # if we ignore checksums. Check that we get the right message, too.
-command_like(['pg_validatebackup', '-s', $backup_path ],
+command_like(['pg_verifybackup', '-s', $backup_path ],
 			 qr/backup successfully verified/,
 			 '-s skips checksumming');
 
 # Validation should succeed if we ignore the problem file.
-command_like(['pg_validatebackup', '-i', 'PG_VERSION', $backup_path ],
+command_like(['pg_verifybackup', '-i', 'PG_VERSION', $backup_path ],
 			 qr/backup successfully verified/,
 			 '-i ignores problem file');
 
@@ -53,19 +53,19 @@ command_like(['pg_validatebackup', '-i', 'PG_VERSION', $backup_path ],
 rmtree($backup_path . "/pg_xact");
 
 # We're ignoring the problem with PG_VERSION, but not the problem with
-# pg_xact, so validation should fail here.
-command_fails_like(['pg_validatebackup', '-i', 'PG_VERSION', $backup_path ],
+# pg_xact, so verification should fail here.
+command_fails_like(['pg_verifybackup', '-i', 'PG_VERSION', $backup_path ],
 				   qr/pg_xact.*is present in the manifest but not on disk/,
 				   '-i does not ignore all problems');
 
 # If we use -i twice, we should be able to ignore all of the problems.
-command_like(['pg_validatebackup', '-i', 'PG_VERSION', '-i', 'pg_xact',
+command_like(['pg_verifybackup', '-i', 'PG_VERSION', '-i', 'pg_xact',
 				$backup_path ],
 			 qr/backup successfully verified/,
 			 'multiple -i options work');
 
 # Verify that when -i is not used, both problems are reported.
-$result = IPC::Run::run ['pg_validatebackup', $backup_path ],
+$result = IPC::Run::run ['pg_verifybackup', $backup_path ],
 	'>', \$stdout, '2>', \$stderr;
 ok(!$result, "multiple problems: fails");
 like($stderr, qr/pg_xact.*is present in the manifest but not on disk/,
@@ -74,7 +74,7 @@ like($stderr, qr/checksum mismatch for file \"PG_VERSION\"/,
 	 "multiple problems: checksum mismatch reported");
 
 # Verify that when -e is used, only the problem detected first is reported.
-$result = IPC::Run::run ['pg_validatebackup', '-e', $backup_path ],
+$result = IPC::Run::run ['pg_verifybackup', '-e', $backup_path ],
 	'>', \$stdout, '2>', \$stderr;
 ok(!$result, "-e reports 1 error: fails");
 like($stderr, qr/pg_xact.*is present in the manifest but not on disk/,
@@ -83,7 +83,7 @@ unlike($stderr, qr/checksum mismatch for file \"PG_VERSION\"/,
 	   "-e reports 1 error: checksum mismatch not reported");
 
 # Test valid manifest with nonexistent backup directory.
-command_fails_like(['pg_validatebackup', '-m', "$backup_path/backup_manifest",
+command_fails_like(['pg_verifybackup', '-m', "$backup_path/backup_manifest",
 						"$backup_path/fake" ],
 				   qr/could not open directory/,
 				   'nonexistent backup directory');
diff --git a/src/bin/pg_validatebackup/t/005_bad_manifest.pl b/src/bin/pg_verifybackup/t/005_bad_manifest.pl
similarity index 97%
rename from src/bin/pg_validatebackup/t/005_bad_manifest.pl
rename to src/bin/pg_verifybackup/t/005_bad_manifest.pl
index f52a8b71ea..3dd2b5a20d 100644
--- a/src/bin/pg_validatebackup/t/005_bad_manifest.pl
+++ b/src/bin/pg_verifybackup/t/005_bad_manifest.pl
@@ -1,4 +1,4 @@
-# Test the behavior of pg_validatebackup when the backup manifest has
+# Test the behavior of pg_verifybackup when the backup manifest has
 # problems.
 
 use strict;
@@ -198,7 +198,7 @@ sub test_bad_manifest
 	print $fh $manifest_contents;
 	close($fh);
 
-	command_fails_like(['pg_validatebackup', $tempdir], $regexp,
+	command_fails_like(['pg_verifybackup', $tempdir], $regexp,
 					   $test_name);
 	return;
 }
diff --git a/src/bin/pg_validatebackup/t/006_encoding.pl b/src/bin/pg_verifybackup/t/006_encoding.pl
similarity index 79%
rename from src/bin/pg_validatebackup/t/006_encoding.pl
rename to src/bin/pg_verifybackup/t/006_encoding.pl
index 5e3e7152a5..3c6b57adcd 100644
--- a/src/bin/pg_validatebackup/t/006_encoding.pl
+++ b/src/bin/pg_verifybackup/t/006_encoding.pl
@@ -1,4 +1,4 @@
-# Verify that pg_validatebackup handles hex-encoded filenames correctly.
+# Verify that pg_verifybackup handles hex-encoded filenames correctly.
 
 use strict;
 use warnings;
@@ -22,6 +22,6 @@ my $count_of_encoded_path_in_manifest =
 cmp_ok($count_of_encoded_path_in_manifest, '>', 100,
 	   "many paths are encoded in the manifest");
 
-command_like(['pg_validatebackup', '-s', $backup_path ],
+command_like(['pg_verifybackup', '-s', $backup_path ],
 			 qr/backup successfully verified/,
-			 'backup with forced encoding validated');
+			 'backup with forced encoding verified');
diff --git a/src/bin/pg_validatebackup/t/007_wal.pl b/src/bin/pg_verifybackup/t/007_wal.pl
similarity index 81%
rename from src/bin/pg_validatebackup/t/007_wal.pl
rename to src/bin/pg_verifybackup/t/007_wal.pl
index b755e0f5e7..5e891d1b6f 100644
--- a/src/bin/pg_validatebackup/t/007_wal.pl
+++ b/src/bin/pg_verifybackup/t/007_wal.pl
@@ -1,4 +1,4 @@
-# Test pg_validatebackup's WAL validation.
+# Test pg_verifybackup's WAL verification.
 
 use strict;
 use warnings;
@@ -22,17 +22,17 @@ my $original_pg_wal = $backup_path . '/pg_wal';
 my $relocated_pg_wal = $master->backup_dir . '/relocated_pg_wal';
 rename($original_pg_wal, $relocated_pg_wal) || die "rename pg_wal: $!";
 
-# WAL validation should fail.
-command_fails_like(['pg_validatebackup', $backup_path ],
+# WAL verification should fail.
+command_fails_like(['pg_verifybackup', $backup_path ],
 				   qr/WAL parsing failed for timeline 1/,
 				   'missing pg_wal causes failure');
 
 # Should work if we skip WAL verification.
-command_ok(['pg_validatebackup', '-n', $backup_path ],
+command_ok(['pg_verifybackup', '-n', $backup_path ],
 		   'missing pg_wal OK if not verifying WAL');
 
 # Should also work if we specify the correct WAL location.
-command_ok(['pg_validatebackup', '-w', $relocated_pg_wal, $backup_path ],
+command_ok(['pg_verifybackup', '-w', $relocated_pg_wal, $backup_path ],
 		   '-w can be used to specify WAL directory');
 
 # Move directory back to original location.
@@ -49,7 +49,7 @@ open(my $fh, '>', $wal_corruption_target)
 print $fh 'w' x $wal_size;
 close($fh);
 
-# WAL validation should fail.
-command_fails_like(['pg_validatebackup', $backup_path ],
+# WAL verification should fail.
+command_fails_like(['pg_verifybackup', $backup_path ],
 				   qr/WAL parsing failed for timeline 1/,
 				   'corrupt WAL file causes failure');
-- 
2.17.2 (Apple Git-113)

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Robert Haas (#1)
Re: pg_validatebackup -> pg_verifybackup?

Robert Haas <robertmhaas@gmail.com> writes:

Over at /messages/by-id/172c9d9b-1d0a-1b94-1456-376b1e017322@2ndquadrant.com
Peter Eisentraut suggests that pg_validatebackup should be called
pg_verifybackup, with corresponding terminology changes throughout the
code and documentation.

Here's a patch for that. I'd like to commit this quickly or abandon in
quickly, because large renaming patches like this are a pain to
maintain. I believe that there was a mild consensus in favor of this
on that thread, so I plan to go forward unless somebody shows up
pretty quickly to object.

+1, let's get it done.

regards, tom lane

#3David Steele
david@pgmasters.net
In reply to: Tom Lane (#2)
Re: pg_validatebackup -> pg_verifybackup?

On 4/10/20 11:37 AM, Tom Lane wrote:

Robert Haas <robertmhaas@gmail.com> writes:

Over at /messages/by-id/172c9d9b-1d0a-1b94-1456-376b1e017322@2ndquadrant.com
Peter Eisentraut suggests that pg_validatebackup should be called
pg_verifybackup, with corresponding terminology changes throughout the
code and documentation.

Here's a patch for that. I'd like to commit this quickly or abandon in
quickly, because large renaming patches like this are a pain to
maintain. I believe that there was a mild consensus in favor of this
on that thread, so I plan to go forward unless somebody shows up
pretty quickly to object.

+1, let's get it done.

I'm not sure that Peter suggested verify was the correct name, he just
pointed out that verify and validate are not necessarily the same thing
(and that we should be consistent in the docs one way or the other).
It'd be nice if Peter (now CC'd) commented since he's the one who
brought it up.

Having said that, I'm +1 on verify.

Regards,
--
-David
david@pgmasters.net

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: David Steele (#3)
Re: pg_validatebackup -> pg_verifybackup?

David Steele <david@pgmasters.net> writes:

Having said that, I'm +1 on verify.

Me too, if only because it's shorter.

regards, tom lane

#5David Steele
david@pgmasters.net
In reply to: Tom Lane (#4)
Re: pg_validatebackup -> pg_verifybackup?

On 4/10/20 3:27 PM, Tom Lane wrote:

David Steele <david@pgmasters.net> writes:

Having said that, I'm +1 on verify.

Me too, if only because it's shorter.

I also think it is (probably) more correct but failing that it is
*definitely* shorter!

--
-David
david@pgmasters.net

#6Andres Freund
andres@anarazel.de
In reply to: David Steele (#3)
Re: pg_validatebackup -> pg_verifybackup?

Hi,

On 2020-04-10 14:56:48 -0400, David Steele wrote:

On 4/10/20 11:37 AM, Tom Lane wrote:

Robert Haas <robertmhaas@gmail.com> writes:

Over at /messages/by-id/172c9d9b-1d0a-1b94-1456-376b1e017322@2ndquadrant.com
Peter Eisentraut suggests that pg_validatebackup should be called
pg_verifybackup, with corresponding terminology changes throughout the
code and documentation.

Here's a patch for that. I'd like to commit this quickly or abandon in
quickly, because large renaming patches like this are a pain to
maintain. I believe that there was a mild consensus in favor of this
on that thread, so I plan to go forward unless somebody shows up
pretty quickly to object.

+1, let's get it done.

I'm not sure that Peter suggested verify was the correct name, he just
pointed out that verify and validate are not necessarily the same thing (and
that we should be consistent in the docs one way or the other). It'd be nice
if Peter (now CC'd) commented since he's the one who brought it up.

Having said that, I'm +1 on verify.

FWIW, I still think it's a mistake to accumulate all these bespoke
tools. We should go towards having one tool that can verify checksums,
validate backup manifests etc. Partially because it's more discoverable,
but also because it allows to verify multiple such properties in a
single pass, rather than reading the huge base backup twice.

Greetings,

Andres Freund

#7Stephen Frost
sfrost@snowman.net
In reply to: Andres Freund (#6)
Re: pg_validatebackup -> pg_verifybackup?

Greetings,

* Andres Freund (andres@anarazel.de) wrote:

On 2020-04-10 14:56:48 -0400, David Steele wrote:

On 4/10/20 11:37 AM, Tom Lane wrote:

Robert Haas <robertmhaas@gmail.com> writes:

Over at /messages/by-id/172c9d9b-1d0a-1b94-1456-376b1e017322@2ndquadrant.com
Peter Eisentraut suggests that pg_validatebackup should be called
pg_verifybackup, with corresponding terminology changes throughout the
code and documentation.

Here's a patch for that. I'd like to commit this quickly or abandon in
quickly, because large renaming patches like this are a pain to
maintain. I believe that there was a mild consensus in favor of this
on that thread, so I plan to go forward unless somebody shows up
pretty quickly to object.

+1, let's get it done.

I'm not sure that Peter suggested verify was the correct name, he just
pointed out that verify and validate are not necessarily the same thing (and
that we should be consistent in the docs one way or the other). It'd be nice
if Peter (now CC'd) commented since he's the one who brought it up.

Having said that, I'm +1 on verify.

FWIW, I still think it's a mistake to accumulate all these bespoke
tools. We should go towards having one tool that can verify checksums,
validate backup manifests etc. Partially because it's more discoverable,
but also because it allows to verify multiple such properties in a
single pass, rather than reading the huge base backup twice.

Would be kinda neat to have a single tool for doing backups and restores
too, as well as validating backup manifests and checksums, that can back
up to s3 or to a remote system with ssh, has multiple compression
options and a pretty sound architecture that's all written in C and is
OSS.

I also agree with Tom/David that verify probably makes sense for this
command, in its current form at least.

Thanks,

Stephen

#8Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andres Freund (#6)
Re: pg_validatebackup -> pg_verifybackup?

Andres Freund <andres@anarazel.de> writes:

FWIW, I still think it's a mistake to accumulate all these bespoke
tools. We should go towards having one tool that can verify checksums,
validate backup manifests etc. Partially because it's more discoverable,
but also because it allows to verify multiple such properties in a
single pass, rather than reading the huge base backup twice.

Well, we're not getting there for v13. Are you proposing that this
patch just be reverted because it doesn't do everything at once?

regards, tom lane

#9Andres Freund
andres@anarazel.de
In reply to: Tom Lane (#8)
Re: pg_validatebackup -> pg_verifybackup?

Hi,

On 2020-04-10 16:13:18 -0400, Tom Lane wrote:

Andres Freund <andres@anarazel.de> writes:

FWIW, I still think it's a mistake to accumulate all these bespoke
tools. We should go towards having one tool that can verify checksums,
validate backup manifests etc. Partially because it's more discoverable,
but also because it allows to verify multiple such properties in a
single pass, rather than reading the huge base backup twice.

Well, we're not getting there for v13. Are you proposing that this
patch just be reverted because it doesn't do everything at once?

No. I suggest choosing a name that's compatible with moving more
capabilities under the same umbrella at a later time (and I suggested
the same pre freeze too). Possibly adding a toplevel --verify-manifest
option as the only change besides naming.

Andres

#10Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andres Freund (#9)
Re: pg_validatebackup -> pg_verifybackup?

Andres Freund <andres@anarazel.de> writes:

On 2020-04-10 16:13:18 -0400, Tom Lane wrote:

Well, we're not getting there for v13. Are you proposing that this
patch just be reverted because it doesn't do everything at once?

No. I suggest choosing a name that's compatible with moving more
capabilities under the same umbrella at a later time (and I suggested
the same pre freeze too). Possibly adding a toplevel --verify-manifest
option as the only change besides naming.

It doesn't really seem like either name is problematic from that
standpoint? "Verify backup" isn't prejudging what aspect of the
backup is going to be verified, AFAICS.

regards, tom lane

#11Andres Freund
andres@anarazel.de
In reply to: Tom Lane (#10)
Re: pg_validatebackup -> pg_verifybackup?

Hi,

On 2020-04-10 16:40:02 -0400, Tom Lane wrote:

Andres Freund <andres@anarazel.de> writes:

On 2020-04-10 16:13:18 -0400, Tom Lane wrote:

Well, we're not getting there for v13. Are you proposing that this
patch just be reverted because it doesn't do everything at once?

No. I suggest choosing a name that's compatible with moving more
capabilities under the same umbrella at a later time (and I suggested
the same pre freeze too). Possibly adding a toplevel --verify-manifest
option as the only change besides naming.

It doesn't really seem like either name is problematic from that
standpoint? "Verify backup" isn't prejudging what aspect of the
backup is going to be verified, AFAICS.

My point is that I'd eventually like to see the same tool also be usable
to just verify the checksums of a normal, non-backup, data directory.

We shouldn't end up with pg_verifybackup, pg_checksums,
pg_dbdir_checknofilesmissing, pg_checkpageheaders, ...

Greetings,

Andres Freund

#12Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andres Freund (#11)
Re: pg_validatebackup -> pg_verifybackup?

Andres Freund <andres@anarazel.de> writes:

On 2020-04-10 16:40:02 -0400, Tom Lane wrote:

It doesn't really seem like either name is problematic from that
standpoint? "Verify backup" isn't prejudging what aspect of the
backup is going to be verified, AFAICS.

My point is that I'd eventually like to see the same tool also be usable
to just verify the checksums of a normal, non-backup, data directory.

Meh. I would argue that that's an actively BAD idea. The use-cases
are entirely different, the implementation is going to be quite a lot
different, the relevant options are going to be quite a lot different.
It will not be better for either implementors or users to force those
into the same executable.

regards, tom lane

#13Andres Freund
andres@anarazel.de
In reply to: Tom Lane (#12)
Re: pg_validatebackup -> pg_verifybackup?

Hi,

On 2020-04-10 17:23:58 -0400, Tom Lane wrote:

Andres Freund <andres@anarazel.de> writes:

On 2020-04-10 16:40:02 -0400, Tom Lane wrote:

It doesn't really seem like either name is problematic from that
standpoint? "Verify backup" isn't prejudging what aspect of the
backup is going to be verified, AFAICS.

My point is that I'd eventually like to see the same tool also be usable
to just verify the checksums of a normal, non-backup, data directory.

Meh. I would argue that that's an actively BAD idea. The use-cases
are entirely different, the implementation is going to be quite a lot
different, the relevant options are going to be quite a lot different.
It will not be better for either implementors or users to force those
into the same executable.

I don't agree with any of that. Combining the manifest validation with
checksum validation halves the IO. It allows to offload some of the
expense of verifying page level checksums from the primary.

And all of the operations require iterating through data directories,
classify files that are part / not part of a normal data directory, etc.

Greetings,

Andres Freund

#14Robert Haas
robertmhaas@gmail.com
In reply to: Tom Lane (#12)
Re: pg_validatebackup -> pg_verifybackup?

On Fri, Apr 10, 2020 at 5:24 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Meh. I would argue that that's an actively BAD idea. The use-cases
are entirely different, the implementation is going to be quite a lot
different, the relevant options are going to be quite a lot different.
It will not be better for either implementors or users to force those
into the same executable.

I think Andres has a point, but on balance I am more inclined to agree
with you. It may be that in the future it will make sense to organize
things differently, but I would rather arrange them according to what
makes sense now, and then change it later, even though that makes for
some user-visible churn. The thing is that we don't really know what's
going to happen in future releases, and our track record when we try
to guess is very poor. Creating stuff that we hope will get extended
to do this or that in a future release can end up looking really
half-baked if the code doesn't get extended in the anticipated
direction.

I *would* like to find a way to address the proliferation of binaries,
because I've got other things I'd like to do that would require
creating still more of them, and until we come up with a scalable
solution that makes everybody happy, there's going to be progressively
more complaining every time. One possible solution is to adopt the
'git' approach and decide we're going to have one 'pg' command (or
whatever we call it). I think the way that 'git' does it is that all
of the real binaries are stored in a directory that users are not
expected to have in their path, and the 'git' wrapper just looks for
one based on the name of the subcommand. So, if you say 'git thunk',
it goes and searches the private bin directory for an executable
called 'git-thunk'. We could easily do this for nearly everything 'pg'
related, so:

clusterdb -> pg clusterdb
pg_ctl -> pg ctl
pg_resetwal -> pg resetwal
etc.

I think we'd want psql to still be separate, but I'm not sure we'd
need any other exceptions. In a lot of cases it won't lead to any more
typing because the current command is pg_whatever and with this
approach you'd just type a space instead of an underscore. The
"legacy" cases that don't start with "pg" would get a bit longer, but
I wouldn't lose a lot of sleep over that myself.

There are other possibilities too. We could try to pick out individual
groups of commands to merge, rather than having a unified framework
for everything. For instance, we could turn
{cluster,create,drop,reindex,vacuum}db into one utility,
{create,drop}user into another, pg_dump{,all} into a third, and so on.
But this seems like it would require making a lot more awkward policy
decisions, so I don't think it's a great plan.

Still, we need to agree on something. It won't do to tell people that
we're not going to commit patches to add more functionality to
PostgreSQL because it would involve adding more binaries. Any
particular piece of functionality may draw substantive objections, and
that's fine, but we shouldn't stifle development categorically because
we can't agree on how to clean up the namespace pollution.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

#15Alvaro Herrera
alvherre@2ndquadrant.com
In reply to: Robert Haas (#14)
Re: pg_validatebackup -> pg_verifybackup?

On 2020-Apr-11, Robert Haas wrote:

I *would* like to find a way to address the proliferation of binaries,
because I've got other things I'd like to do that would require
creating still more of them, and until we come up with a scalable
solution that makes everybody happy, there's going to be progressively
more complaining every time. One possible solution is to adopt the
'git' approach and decide we're going to have one 'pg' command (or
whatever we call it). I think the way that 'git' does it is that all
of the real binaries are stored in a directory that users are not
expected to have in their path, and the 'git' wrapper just looks for
one based on the name of the subcommand.

I like this idea so much that I already proposed it in the past[1]/messages/by-id/20160826202911.GA320593@alvherre.pgsql, so +1.

[1]: /messages/by-id/20160826202911.GA320593@alvherre.pgsql

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

#16Michael Paquier
michael@paquier.xyz
In reply to: Andres Freund (#13)
Re: pg_validatebackup -> pg_verifybackup?

On Fri, Apr 10, 2020 at 02:48:05PM -0700, Andres Freund wrote:

I don't agree with any of that. Combining the manifest validation with
checksum validation halves the IO. It allows to offload some of the
expense of verifying page level checksums from the primary.

And all of the operations require iterating through data directories,
classify files that are part / not part of a normal data directory, etc.

The last time we had the idea to use _verify_ in a tool name, the same
tool has been renamed one year after as we found new use cases for
it, aka pg_checksums. Cannot the same be said with pg_validatebackup?
It seems to me that it could be interesting for some users to build a
manifest after a backup is taken, using something like a --build
option with pg_validatebackup.
--
Michael

#17Michael Paquier
michael@paquier.xyz
In reply to: Alvaro Herrera (#15)
Re: pg_validatebackup -> pg_verifybackup?

On Sat, Apr 11, 2020 at 05:50:56PM -0400, Alvaro Herrera wrote:

On 2020-Apr-11, Robert Haas wrote:

I *would* like to find a way to address the proliferation of binaries,
because I've got other things I'd like to do that would require
creating still more of them, and until we come up with a scalable
solution that makes everybody happy, there's going to be progressively
more complaining every time. One possible solution is to adopt the
'git' approach and decide we're going to have one 'pg' command (or
whatever we call it). I think the way that 'git' does it is that all
of the real binaries are stored in a directory that users are not
expected to have in their path, and the 'git' wrapper just looks for
one based on the name of the subcommand.

I like this idea so much that I already proposed it in the past[1], so +1.

[1] /messages/by-id/20160826202911.GA320593@alvherre.pgsql

Yeah, their stuff is nice. Another nice thing is that git has the
possibility to scan as well for custom scripts as long as they respect
the naming convention, like having a custom script called "git-foo",
that can be called as "git foo".
--
Michael

#18Isaac Morland
isaac.morland@gmail.com
In reply to: Michael Paquier (#17)
Re: pg_validatebackup -> pg_verifybackup?

On Sat, 11 Apr 2020 at 19:36, Michael Paquier <michael@paquier.xyz> wrote:

Yeah, their stuff is nice. Another nice thing is that git has the
possibility to scan as well for custom scripts as long as they respect
the naming convention, like having a custom script called "git-foo",
that can be called as "git foo".

… which could be installed by an extension perhaps. Wait, that doesn't
quite work because it's usually one bin directory per version, not per
database. Still maybe something can be done with that idea.

#19Robert Haas
robertmhaas@gmail.com
In reply to: Alvaro Herrera (#15)
Re: pg_validatebackup -> pg_verifybackup?

On Sat, Apr 11, 2020 at 5:51 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:

I like this idea so much that I already proposed it in the past[1], so +1.

[1] /messages/by-id/20160826202911.GA320593@alvherre.pgsql

Hey, look at that. I think I had some vague recollection of a prior
proposal, but I couldn't remember exactly who or exactly what had been
proposed. I do think that pg_ctl is too long a prefix, though. People
can get used to typing 'pg createdb' instead of 'createdb' but 'pg_ctl
createdb' seems like too much. At least, it would very very quickly
cause me to install aliases.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

#20Tom Lane
tgl@sss.pgh.pa.us
In reply to: Robert Haas (#19)
Re: pg_validatebackup -> pg_verifybackup?

Robert Haas <robertmhaas@gmail.com> writes:

On Sat, Apr 11, 2020 at 5:51 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:

I like this idea so much that I already proposed it in the past[1], so +1.

[1] /messages/by-id/20160826202911.GA320593@alvherre.pgsql

Hey, look at that. I think I had some vague recollection of a prior
proposal, but I couldn't remember exactly who or exactly what had been
proposed. I do think that pg_ctl is too long a prefix, though. People
can get used to typing 'pg createdb' instead of 'createdb' but 'pg_ctl
createdb' seems like too much. At least, it would very very quickly
cause me to install aliases.

Yeah, I'd be happier with "pg" than "pg_ctl" as well. But it's so
short that I wonder if some other software has already adopted it.

regards, tom lane

#21Magnus Hagander
magnus@hagander.net
In reply to: Tom Lane (#20)
Re: pg_validatebackup -> pg_verifybackup?

On Sun, Apr 12, 2020 at 4:58 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Robert Haas <robertmhaas@gmail.com> writes:

On Sat, Apr 11, 2020 at 5:51 PM Alvaro Herrera <alvherre@2ndquadrant.com>

wrote:

I like this idea so much that I already proposed it in the past[1], so

+1.

[1] /messages/by-id/20160826202911.GA320593@alvherre.pgsql

Hey, look at that. I think I had some vague recollection of a prior
proposal, but I couldn't remember exactly who or exactly what had been
proposed. I do think that pg_ctl is too long a prefix, though. People
can get used to typing 'pg createdb' instead of 'createdb' but 'pg_ctl
createdb' seems like too much. At least, it would very very quickly
cause me to install aliases.

Yeah, I'd be happier with "pg" than "pg_ctl" as well. But it's so
short that I wonder if some other software has already adopted it.

There's https://en.wikipedia.org/wiki/Pg_(Unix).

So it's been removed from posix, but not unlikely to be around. For
example, I see it on a server with Debian 9 (Stretch) or Ubuntu 16.04 which
is still well in support (but not on a RedHat from the same era).

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/&gt;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/&gt;

#22Robert Haas
robertmhaas@gmail.com
In reply to: Magnus Hagander (#21)
Re: pg_validatebackup -> pg_verifybackup?

On Sun, Apr 12, 2020 at 11:02 AM Magnus Hagander <magnus@hagander.net> wrote:

There's https://en.wikipedia.org/wiki/Pg_(Unix).

So it's been removed from posix, but not unlikely to be around. For example, I see it on a server with Debian 9 (Stretch) or Ubuntu 16.04 which is still well in support (but not on a RedHat from the same era).

Well, if it's around on older distros, but not in the newest versions,
I think we should try to lay speedy claim to the name before something
else does, because any other name we pick is going to be longer or
less intuitive or, most likely, both. There's no guarantee that
PostgreSQL 14 would even get packaged for older distros, anyway, or at
least not by the OS provider.

We could also have an alternate name, like pgsql, and make 'pg' a
symlink to it that packagers can choose to omit. (I would prefer pgsql
to pg_ctl, both because I think it's confusing to adopt the name of an
existing tool as the meta-command and also because the underscore
requires pressing two keys at once, which is slightly slower to type).
But there is no way anyone who is a serious user is going to be happy
with a five-character meta-command name that requires six key-presses
to enter (cf. cvs, git, hg, yum, pip, apt, ...).

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

#23Magnus Hagander
magnus@hagander.net
In reply to: Robert Haas (#22)
Re: pg_validatebackup -> pg_verifybackup?

On Sun, Apr 12, 2020 at 5:22 PM Robert Haas <robertmhaas@gmail.com> wrote:

On Sun, Apr 12, 2020 at 11:02 AM Magnus Hagander <magnus@hagander.net>
wrote:

There's https://en.wikipedia.org/wiki/Pg_(Unix).

So it's been removed from posix, but not unlikely to be around. For

example, I see it on a server with Debian 9 (Stretch) or Ubuntu 16.04 which
is still well in support (but not on a RedHat from the same era).

Well, if it's around on older distros, but not in the newest versions,
I think we should try to lay speedy claim to the name before something
else does, because any other name we pick is going to be longer or
less intuitive or, most likely, both. There's no guarantee that
PostgreSQL 14 would even get packaged for older distros, anyway, or at
least not by the OS provider.

It definitely won't be by the OS provider, however it will be by *us*. Our
apt and yum repositories support all our versions on "all supported"
versions of the upstream distros. So we should at least have a plan and a
story for how to deal with that, and make sure all our own packagers deal
with it the same way.

We could also have an alternate name, like pgsql, and make 'pg' a

symlink to it that packagers can choose to omit. (I would prefer pgsql
to pg_ctl, both because I think it's confusing to adopt the name of an
existing tool as the meta-command and also because the underscore
requires pressing two keys at once, which is slightly slower to type).
But there is no way anyone who is a serious user is going to be happy
with a five-character meta-command name that requires six key-presses
to enter (cf. cvs, git, hg, yum, pip, apt, ...).

Agreed, pgsql would certainly be better than pg_ctl.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/&gt;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/&gt;

#24Andres Freund
andres@anarazel.de
In reply to: Tom Lane (#20)
Re: pg_validatebackup -> pg_verifybackup?

Hi,

On 2020-04-12 10:57:59 -0400, Tom Lane wrote:

Yeah, I'd be happier with "pg" than "pg_ctl" as well. But it's so
short that I wonder if some other software has already adopted it.

FWIW, Debian unstable does not have a 'pg' binary. There's a few modules
in various languages called 'pg', but that's not a problem.

I personally think it might be a good idea to 'claim' the pg binary
soon, so that doesn't change. Even if we should support a command or two
through it initially (e.g. pg_ctl ... -> pg ctl ...).

Regards,

Andres Freund

#25Andres Freund
andres@anarazel.de
In reply to: Robert Haas (#22)
Re: pg_validatebackup -> pg_verifybackup?

On 2020-04-12 11:21:50 -0400, Robert Haas wrote:

We could also have an alternate name, like pgsql, and make 'pg' a
symlink to it that packagers can choose to omit.

We could even name the non-abbreviated binary postgres :).

Sure, that'd cause a bit more trouble upgrading for people that scripted
starting postgres without going through pg_ctl or such, but OTOH it'd
not cause new naming conflicts. And all that'd be needed to fix the
start script would be 's/postgres/postgres server/'.

- Andres

#26Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andres Freund (#25)
Re: pg_validatebackup -> pg_verifybackup?

Andres Freund <andres@anarazel.de> writes:

On 2020-04-12 11:21:50 -0400, Robert Haas wrote:

We could also have an alternate name, like pgsql, and make 'pg' a
symlink to it that packagers can choose to omit.

We could even name the non-abbreviated binary postgres :).

I shudder to imagine the confusion that would result.

regards, tom lane

In reply to: Tom Lane (#26)
1 attachment(s)
RE: pg_validatebackup -> pg_verifybackup?

Hi,

Sorry this email is not a discussion about word selection.
Since part of the manual had left pg_validatebackup in commit dbc60c5593f26dc777a3be032bff4fb4eab1ddd1.
I've attached a patch to fix this.

Regards,
Noriyoshi Shinoda

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Monday, April 13, 2020 5:07 AM
To: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>; Magnus Hagander <magnus@hagander.net>; Alvaro Herrera <alvherre@2ndquadrant.com>; David Steele <david@pgmasters.net>; pgsql-hackers@postgresql.org; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Subject: Re: pg_validatebackup -> pg_verifybackup?

Andres Freund <andres@anarazel.de> writes:

On 2020-04-12 11:21:50 -0400, Robert Haas wrote:

We could also have an alternate name, like pgsql, and make 'pg' a
symlink to it that packagers can choose to omit.

We could even name the non-abbreviated binary postgres :).

I shudder to imagine the confusion that would result.

regards, tom lane

Attachments:

pg_verifybackup.sgml.diffapplication/octet-stream; name=pg_verifybackup.sgml.diffDownload
diff --git a/doc/src/sgml/ref/pg_verifybackup.sgml b/doc/src/sgml/ref/pg_verifybackup.sgml
index 0ab92b3..8341dfd 100644
--- a/doc/src/sgml/ref/pg_verifybackup.sgml
+++ b/doc/src/sgml/ref/pg_verifybackup.sgml
@@ -132,7 +132,7 @@ PostgreSQL documentation
       <listitem>
        <para>
         Exit as soon as a problem with the backup is detected. If this option
-        is not specified, <literal>pg_validatebackup</literal> will continue
+        is not specified, <literal>pg_verifybackup</literal> will continue
         checking the backup even after a problem has been detected, and will
         report all problems detected as errors.
        </para>
#28Kyotaro Horiguchi
horikyota.ntt@gmail.com
In reply to: Magnus Hagander (#23)
Re: pg_validatebackup -> pg_verifybackup?

I recklessly join the discussion about naming.

At Sun, 12 Apr 2020 17:29:55 +0200, Magnus Hagander <magnus@hagander.net> wrote in

Agreed, pgsql would certainly be better than pg_ctl.

I like pgsql. And if we are going to join to the THREE-LETTERS
CONTROLLER COMMANDS ALLIANCE, pgc (pg controller) might be a candidate
of the controller program.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

#29Robert Haas
robertmhaas@gmail.com
In reply to: Shinoda, Noriyoshi (PN Japan A&PS Delivery) (#27)
Re: pg_validatebackup -> pg_verifybackup?

On Sun, Apr 12, 2020 at 10:20 PM Shinoda, Noriyoshi (PN Japan A&PS
Delivery) <noriyoshi.shinoda@hpe.com> wrote:

Sorry this email is not a discussion about word selection.
Since part of the manual had left pg_validatebackup in commit dbc60c5593f26dc777a3be032bff4fb4eab1ddd1.
I've attached a patch to fix this.

Committed, thanks.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company