| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Have better wording for snapshot file reading failure |
| Date: | 2023-09-14 02:07:24 |
| Message-ID: | 20230914020724.hlks7vunitvtbbz4@awork3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2023-09-14 02:09:32 | Re: Have better wording for snapshot file reading failure |
| Previous Message | Michael Paquier | 2023-09-14 01:50:18 | Re: persist logical slots to disk during shutdown checkpoint |