Horton
Menu

Thread

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

  1. Have better wording for snapshot file reading failure

    Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> — 2023-09-13T06:10:25Z

    Hi,

When a snapshot file reading fails in ImportSnapshot(), it errors out
with "invalid snapshot identifier". This message better suits for
snapshot identifier parsing errors which is being done just before the
file reading. The attached patch adds a generic file reading error
message with path to help distinguish if the issue is with snapshot
identifier parsing or file reading.

-- 
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

  2. Re: Have better wording for snapshot file reading failure

    Michael Paquier <michael@paquier.xyz> — 2023-09-13T06:18:00Z

    On Wed, Sep 13, 2023 at 11:40:25AM +0530, Bharath Rupireddy wrote:
> When a snapshot file reading fails in ImportSnapshot(), it errors out
> with "invalid snapshot identifier". This message better suits for
> snapshot identifier parsing errors which is being done just before the
> file reading. The attached patch adds a generic file reading error
> message with path to help distinguish if the issue is with snapshot
> identifier parsing or file reading.

     f = AllocateFile(path, PG_BINARY_R);
     if (!f)
         ereport(ERROR,
-                (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
-                 errmsg("invalid snapshot identifier: \"%s\"", idstr)));
+                (errcode_for_file_access(),
+                 errmsg("could not open file \"%s\" for reading: %m",
+                        path)));

Agreed that this just looks like a copy-pasto.  The path provides
enough context about what's being read, so using this generic error
message is fine.  Will apply if there are no objections. 
--
Michael

  3. Re: Have better wording for snapshot file reading failure

    Yogesh Sharma <yogesh.sharma@catprosystems.com> — 2023-09-13T10:02:46Z

    On 9/13/23 02:10, Bharath Rupireddy wrote:
> Hi,
>
> When a snapshot file reading fails in ImportSnapshot(), it errors out
> with "invalid snapshot identifier". This message better suits for
> snapshot identifier parsing errors which is being done just before the
> file reading. The attached patch adds a generic file reading error
> message with path to help distinguish if the issue is with snapshot
> identifier parsing or file reading.
>
I suggest error message to include "snapshot" keyword in message, like this:

errmsg("could not open snapshot file \"%s\" for reading: %m",

and also tweak other messages accordingly.


-- 
Kind Regards,
Yogesh Sharma
PostgreSQL, Linux, and Networking Expert
Open Source Enthusiast and Advocate

  4. Re: Have better wording for snapshot file reading failure

    Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> — 2023-09-13T10:52:24Z

    On Wed, Sep 13, 2023 at 3:32 PM Yogesh Sharma
<yogesh.sharma@catprosystems.com> wrote:
>
> On 9/13/23 02:10, Bharath Rupireddy wrote:
> > Hi,
> >
> > When a snapshot file reading fails in ImportSnapshot(), it errors out
> > with "invalid snapshot identifier". This message better suits for
> > snapshot identifier parsing errors which is being done just before the
> > file reading. The attached patch adds a generic file reading error
> > message with path to help distinguish if the issue is with snapshot
> > identifier parsing or file reading.
> >
> I suggest error message to include "snapshot" keyword in message, like this:
>
> errmsg("could not open snapshot file \"%s\" for reading: %m",
>
> and also tweak other messages accordingly.

-1. The path includes the pg_snapshots there which is enough to give
the clue, so no need to say "could not open snapshot file". AFAICS,
this is the typical messaging followed across postgres code for
AllocateFile failures.

[1]
/* Define pathname of exported-snapshot files */
#define SNAPSHOT_EXPORT_DIR "pg_snapshots"

    /* OK, read the file */
    snprintf(path, MAXPGPATH, SNAPSHOT_EXPORT_DIR "/%s", idstr);

    f = AllocateFile(path, PG_BINARY_R);
    if (!f)
        ereport(ERROR,
                (errcode_for_file_access(),
                 errmsg("could not open file \"%s\" for reading: %m",
                        path)));

-- 
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

  5. Re: Have better wording for snapshot file reading failure

    Daniel Gustafsson <daniel@yesql.se> — 2023-09-13T11:19:38Z

    > On 13 Sep 2023, at 08:18, Michael Paquier <michael@paquier.xyz> wrote:

>     f = AllocateFile(path, PG_BINARY_R);
>     if (!f)
>         ereport(ERROR,
> -                (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> -                 errmsg("invalid snapshot identifier: \"%s\"", idstr)));
> +                (errcode_for_file_access(),
> +                 errmsg("could not open file \"%s\" for reading: %m",
> +                        path)));
> 
> Agreed that this just looks like a copy-pasto.  The path provides
> enough context about what's being read, so using this generic error
> message is fine.  Will apply if there are no objections.

+1. This errmsg is already present so it eases the translation burden as well.

--
Daniel Gustafsson

  6. Re: Have better wording for snapshot file reading failure

    Michael Paquier <michael@paquier.xyz> — 2023-09-14T01:33:33Z

    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.
--
Michael

  7. Re: Have better wording for snapshot file reading failure

    Andres Freund <andres@anarazel.de> — 2023-09-14T02:07:24Z

    Hi,

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.

Greetings,

Andres

  8. Re: Have better wording for snapshot file reading failure

    Andres Freund <andres@anarazel.de> — 2023-09-14T02:09:32Z

    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

  9. Re: Have better wording for snapshot file reading failure

    Michael Paquier <michael@paquier.xyz> — 2023-09-14T04:33:39Z

    On Wed, Sep 13, 2023 at 07:09:32PM -0700, Andres Freund wrote:
> On 2023-09-13 19:07:24 -0700, Andres Freund wrote:
>> 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.

Ahem.  This seems to be the only code path that tracks a failure on
AllocateFile() where we don't show %m at all, while the error is
misleading in basically all the cases as errno holds the extra
information telling somebody that something's going wrong, so I don't
quite see how it is useful to tell "invalid snapshot identifier" on
an EACCES or even ENOENT when opening this file, with zero information
about what's happening on top of that?  Even on ENOENT, one can be
confused with the same error message generated a few lines above: if
AllocateFile() fails, the snapshot identifier is correctly shaped, but
its file is missing.  If ENOENT is considered a particular case with
the old message, we'd still not know if this refers to the first
failure or the second failure.

Saying that, I'm OK with reverting to the previous behavior on
back-branches if you feel strongly about that.
--
Michael

  10. Re: Have better wording for snapshot file reading failure

    Michael Paquier <michael@paquier.xyz> — 2023-09-14T07:29:22Z

    On Thu, Sep 14, 2023 at 01:33:39PM +0900, Michael Paquier wrote:
> Ahem.  This seems to be the only code path that tracks a failure on
> AllocateFile() where we don't show %m at all, while the error is
> misleading in basically all the cases as errno holds the extra
> information telling somebody that something's going wrong, so I don't
> quite see how it is useful to tell "invalid snapshot identifier" on
> an EACCES or even ENOENT when opening this file, with zero information
> about what's happening on top of that?  Even on ENOENT, one can be
> confused with the same error message generated a few lines above: if
> AllocateFile() fails, the snapshot identifier is correctly shaped, but
> its file is missing.  If ENOENT is considered a particular case with
> the old message, we'd still not know if this refers to the first
> failure or the second failure.

I see your point after thinking about it, the new message would show
up when running a SET TRANSACTION SNAPSHOT with a value id, which is
not helpful either.  Your idea of filtering out ENOENT may be the best
move to get more information on %m.  Still, it looks to me that using
the same error message for both cases is incorrect.  So, how about a
"could not find the requested snapshot" if the snapshot ID is valid
but its file cannot be found?  We don't have any tests for the failure
paths, either, so I've added some.

This new suggestion is only for HEAD.  I've reverted a0d87bc & co for
now.
--
Michael

  11. Re: Have better wording for snapshot file reading failure

    Andres Freund <andres@anarazel.de> — 2023-09-15T00:33:35Z

    Hi,

On 2023-09-14 16:29:22 +0900, Michael Paquier wrote:
> On Thu, Sep 14, 2023 at 01:33:39PM +0900, Michael Paquier wrote:
> > Ahem.  This seems to be the only code path that tracks a failure on
> > AllocateFile() where we don't show %m at all, while the error is
> > misleading in basically all the cases as errno holds the extra
> > information telling somebody that something's going wrong, so I don't
> > quite see how it is useful to tell "invalid snapshot identifier" on
> > an EACCES or even ENOENT when opening this file, with zero information
> > about what's happening on top of that?  Even on ENOENT, one can be
> > confused with the same error message generated a few lines above: if
> > AllocateFile() fails, the snapshot identifier is correctly shaped, but
> > its file is missing.  If ENOENT is considered a particular case with
> > the old message, we'd still not know if this refers to the first
> > failure or the second failure.
> 
> I see your point after thinking about it, the new message would show
> up when running a SET TRANSACTION SNAPSHOT with a value id, which is
> not helpful either.  Your idea of filtering out ENOENT may be the best
> move to get more information on %m.  Still, it looks to me that using
> the same error message for both cases is incorrect.

I wouldn't call it quite incorrect, but it's certainly a good idea to provide
relevant details for the rare case of errors other than ENOENT.


> So, how about a "could not find the requested snapshot" if the snapshot ID
> is valid but its file cannot be found?

I'd probably just go for something like "snapshot \"%s\" does not exist",
similar to what we report for unknown tables etc. Arguably changing the
errcode to ERRCODE_UNDEFINED_OBJECT would make this more precise?


> This new suggestion is only for HEAD.  I've reverted a0d87bc & co for
> now.

I think there's really no reason to backpatch this, so that makes sense to me.

Greetings,

Andres Freund

  12. Re: Have better wording for snapshot file reading failure

    Michael Paquier <michael@paquier.xyz> — 2023-09-15T05:20:59Z

    On Thu, Sep 14, 2023 at 05:33:35PM -0700, Andres Freund wrote:
> I'd probably just go for something like "snapshot \"%s\" does not exist",
> similar to what we report for unknown tables etc. Arguably changing the
> errcode to ERRCODE_UNDEFINED_OBJECT would make this more precise?

Good points.  Updated as suggested in v2 attached.
--
Michael

  13. Re: Have better wording for snapshot file reading failure

    Yogesh Sharma <yogesh.sharma@catprosystems.com> — 2023-09-17T12:36:06Z

    On 9/14/23 20:33, Andres Freund wrote:
> I'd probably just go for something like "snapshot \"%s\" does not exist",
> similar to what we report for unknown tables etc. Arguably changing the
> errcode to ERRCODE_UNDEFINED_OBJECT would make this more precise?

+1  better  informative message compare to the original patch.

-- 
Kind Regards,
Yogesh Sharma
PostgreSQL, Linux, and Networking Expert
Open Source Enthusiast and Advocate