Horton
Menu

Re: Have better wording for snapshot file reading failure

Andres Freund <andres@anarazel.de>

View thread
From: Andres Freund <andres@anarazel.de>
To: Michael Paquier <michael@paquier.xyz>
Cc: Daniel Gustafsson <daniel@yesql.se>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-09-14T02:09:32Z
Lists: pgsql-hackers 
Hi,

On 2023-09-13 19:07:24 -0700, Andres Freund wrote:
> On 2023-09-14 10:33:33 +0900, Michael Paquier wrote:
> > On Wed, Sep 13, 2023 at 01:19:38PM +0200, Daniel Gustafsson wrote:
> > > +1. This errmsg is already present so it eases the translation burden as well.
> > 
> > I was thinking about doing only that on HEAD, but there is an argument
> > that one could get confusing errors when dealing with snapshot imports
> > on back-branches as well, and it applies down to 11 without conflicts.
> > So, applied and backpatched.
> 
> Huh. I don't think this is a good idea - and certainly not in the back
> branches. The prior message made more sense, imo. The fact that the snapshot
> identifier is a file is an implementation detail, no snapshot with the
> identifier being exported is a user level detail. Hence that being mentioned
> in the error message.
> 
> I can see an argument for treating ENOENT different than other errors though,
> and using the standard file opening error message for anything other than
> ENOENT.

Oh, and given that this actually changes the error code for an invalid
snapshot, I think this needs to be reverted. It's not that unlikely that
there's code out there that depends on getting ERRCODE_INVALID_PARAMETER_VALUE
when the snapshot doesn't exist.

- Andres

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Improve error message for snapshot import in snapmgr.c, take two

  2. Revert "Improve error message on snapshot import in snapmgr.c"

  3. Improve error message on snapshot import in snapmgr.c