[PATCH] pg_upgrade: report the reason for failing to open the cluster version file

On 26 Feb 2020, at 00:14, Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> wrote:

It would have saved some minutes of debugging time if that had included
the reason why the open failed, so here's a patch to do so.

+1 on the attached patch. A quick skim across the similar error reportings in
pg_upgrade doesn't turn up any others which lack the more detailed information.

-		pg_fatal("could not open version file: %s\n", ver_filename);
+		pg_fatal("could not open version file \"%s\": %m\n", ver_filename);

A few lines further down from this we report an error in case we are unable to
parse the file in question:

pg_fatal("could not parse PG_VERSION file from %s\n", cluster->pgdata);

Should the pgdata argument be quoted there as well, like \"%s\", to make it
consistent for how we report filenames and directories in pg_upgrade?

cheers ./daniel

Daniel Gustafsson <daniel@yesql.se> writes:

A few lines further down from this we report an error in case we are unable to
parse the file in question:

pg_fatal("could not parse PG_VERSION file from %s\n", cluster->pgdata);

Should the pgdata argument be quoted there as well, like \"%s\", to make it
consistent for how we report filenames and directories in pg_upgrade?

Good point, I agree we should. Updated patch attached.

- ilmari
--
"A disappointingly low fraction of the human race is,
at any given time, on fire." - Stig Sandbeck Mathisen

On Tue, Feb 25, 2020 at 11:55:06PM +0000, Dagfinn Ilmari Mannsåker wrote:

@@ -164,11 +164,11 @@ get_major_server_version(ClusterInfo *cluster)
snprintf(ver_filename, sizeof(ver_filename), "%s/PG_VERSION",
cluster->pgdata);
if ((version_fd = fopen(ver_filename, "r")) == NULL)
-		pg_fatal("could not open version file: %s\n", ver_filename);
+		pg_fatal("could not open version file \"%s\": %m\n", ver_filename);

Here I think that it would be better to just use "could not open
file" as we know that we are dealing with a version file already
thanks to ver_filename.

if (fscanf(version_fd, "%63s", cluster->major_version_str) == 0 ||
sscanf(cluster->major_version_str, "%d.%d", &v1, &v2) < 1)
-		pg_fatal("could not parse PG_VERSION file from %s\n", cluster->pgdata);
+		pg_fatal("could not parse PG_VERSION file from \"%s\"\n", cluster->pgdata);

fclose(version_fd);

No objection to this one.
--
Michael

On 26 Feb 2020, at 02:48, Michael Paquier <michael@paquier.xyz> wrote:

On Tue, Feb 25, 2020 at 11:55:06PM +0000, Dagfinn Ilmari Mannsåker wrote:

@@ -164,11 +164,11 @@ get_major_server_version(ClusterInfo *cluster)
snprintf(ver_filename, sizeof(ver_filename), "%s/PG_VERSION",
cluster->pgdata);
if ((version_fd = fopen(ver_filename, "r")) == NULL)
-		pg_fatal("could not open version file: %s\n", ver_filename);
+		pg_fatal("could not open version file \"%s\": %m\n", ver_filename);

Here I think that it would be better to just use "could not open
file" as we know that we are dealing with a version file already
thanks to ver_filename.

Isn't that a removal of detail with very little benefit? Not everyone running
pg_upgrade will know internal filenames, and the ver_filename contains the
pgdata path as well which might provide additional clues in case this goes
wrong.

cheers ./daniel

On Wed, Feb 26, 2020 at 9:56 AM Daniel Gustafsson <daniel@yesql.se> wrote:

On 26 Feb 2020, at 02:48, Michael Paquier <michael@paquier.xyz> wrote:

On Tue, Feb 25, 2020 at 11:55:06PM +0000, Dagfinn Ilmari Mannsåker wrote:

@@ -164,11 +164,11 @@ get_major_server_version(ClusterInfo *cluster)
snprintf(ver_filename, sizeof(ver_filename), "%s/PG_VERSION",
cluster->pgdata);
if ((version_fd = fopen(ver_filename, "r")) == NULL)
-            pg_fatal("could not open version file: %s\n", ver_filename);
+            pg_fatal("could not open version file \"%s\": %m\n", ver_filename);

Here I think that it would be better to just use "could not open
file" as we know that we are dealing with a version file already
thanks to ver_filename.

Isn't that a removal of detail with very little benefit? Not everyone running
pg_upgrade will know internal filenames, and the ver_filename contains the
pgdata path as well which might provide additional clues in case this goes
wrong.

+1, seems like that would be a regression in value.

Committed as per Dagfinn's v2.

--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/

On Wed, Feb 26, 2020 at 10:06:38AM +0100, Magnus Hagander wrote:

+1, seems like that would be a regression in value.

Having more generic messages is less work for translators, we have
PG_VERSION in the file name, and that's more complicated to translate
in both French and Japanese. No idea about other languages.

Committed as per Dagfinn's v2.

Anyway, too late :)
--
Michael

Michael Paquier <michael@paquier.xyz> writes:

On Wed, Feb 26, 2020 at 10:06:38AM +0100, Magnus Hagander wrote:

+1, seems like that would be a regression in value.

Having more generic messages is less work for translators, we have
PG_VERSION in the file name, and that's more complicated to translate
in both French and Japanese. No idea about other languages.

Just looking at the committed diff, it seems painfully obvious that these
two messages were written by different people who weren't talking to each
other. Why aren't they more alike? Given

pg_fatal("could not open version file \"%s\": %m\n", ver_filename);

(which seems fine to me), I think the second ought to be

pg_fatal("could not parse version file \"%s\"\n", ver_filename);

The wording as it stands:

pg_fatal("could not parse PG_VERSION file from \"%s\"\n", cluster->pgdata);

could be criticized on more grounds than just that it's pointlessly
different from the adjacent message: it doesn't follow the style guideline
about saying what each mentioned object is. You could fix that maybe with
s/from/from directory/, but I think this construction is unfortunate and
overly verbose already.

regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> writes:

Michael Paquier <michael@paquier.xyz> writes:

On Wed, Feb 26, 2020 at 10:06:38AM +0100, Magnus Hagander wrote:

+1, seems like that would be a regression in value.

Having more generic messages is less work for translators, we have
PG_VERSION in the file name, and that's more complicated to translate
in both French and Japanese. No idea about other languages.

Just looking at the committed diff, it seems painfully obvious that these
two messages were written by different people who weren't talking to each
other. Why aren't they more alike? Given

pg_fatal("could not open version file \"%s\": %m\n", ver_filename);

(which seems fine to me), I think the second ought to be

pg_fatal("could not parse version file \"%s\"\n", ver_filename);

Good point. Patch attached.

- ilmari
--
- Twitter seems more influential [than blogs] in the 'gets reported in
the mainstream press' sense at least. - Matt McLeod
- That'd be because the content of a tweet is easier to condense down
to a mainstream media article. - Calle Dybedahl

On Wed, Feb 26, 2020 at 06:32:00PM +0000, Dagfinn Ilmari Manns�ker wrote:

Tom Lane <tgl@sss.pgh.pa.us> writes:

Michael Paquier <michael@paquier.xyz> writes:

On Wed, Feb 26, 2020 at 10:06:38AM +0100, Magnus Hagander wrote:

+1, seems like that would be a regression in value.

Having more generic messages is less work for translators, we have
PG_VERSION in the file name, and that's more complicated to translate
in both French and Japanese. No idea about other languages.

Just looking at the committed diff, it seems painfully obvious that these
two messages were written by different people who weren't talking to each
other. Why aren't they more alike? Given

pg_fatal("could not open version file \"%s\": %m\n", ver_filename);

(which seems fine to me), I think the second ought to be

pg_fatal("could not parse version file \"%s\"\n", ver_filename);

Good point. Patch attached.

Patch applied, and other adjustments:

This patch fixes the error message in get_major_server_version()
to be "could not parse version file", and uses the full file path
name, rather than just the data directory path.

Also, commit 4109bb5de4 added the cause of the failure to the
"could not open" error message, and improved quoting. This patch
backpatches the "could not open" cause to PG 12, where it was
first widely used, and backpatches the quoting fix in that patch
to all supported releases.

Because some of the branches are different, I am attaching the applied
multi-version patch.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

Bruce Momjian <bruce@momjian.us> writes:

On Wed, Feb 26, 2020 at 06:32:00PM +0000, Dagfinn Ilmari Mannsåker wrote:

Tom Lane <tgl@sss.pgh.pa.us> writes:

Michael Paquier <michael@paquier.xyz> writes:

On Wed, Feb 26, 2020 at 10:06:38AM +0100, Magnus Hagander wrote:

+1, seems like that would be a regression in value.

Having more generic messages is less work for translators, we have
PG_VERSION in the file name, and that's more complicated to translate
in both French and Japanese. No idea about other languages.

Just looking at the committed diff, it seems painfully obvious that these
two messages were written by different people who weren't talking to each
other. Why aren't they more alike? Given

pg_fatal("could not open version file \"%s\": %m\n", ver_filename);

(which seems fine to me), I think the second ought to be

pg_fatal("could not parse version file \"%s\"\n", ver_filename);

Good point. Patch attached.

Patch applied, and other adjustments:

Thanks!

- ilmari
--
- Twitter seems more influential [than blogs] in the 'gets reported in
the mainstream press' sense at least. - Matt McLeod
- That'd be because the content of a tweet is easier to condense down
to a mainstream media article. - Calle Dybedahl