From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
---|---|
To: | Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: [PATCH] pg_upgrade: report the reason for failing to open the cluster version file |
Date: | 2020-02-25 23:31:26 |
Message-ID: | 44115C15-EE49-4BDE-A976-2901384B5E60@yesql.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 26 Feb 2020, at 00:14, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Dagfinn Ilmari Mannsåker | 2020-02-25 23:55:06 | Re: [PATCH] pg_upgrade: report the reason for failing to open the cluster version file |
Previous Message | Dagfinn Ilmari Mannsåker | 2020-02-25 23:14:06 | [PATCH] pg_upgrade: report the reason for failing to open the cluster version file |