| From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Cc: | Sergei Kornilov <sk(at)zsrv(dot)org>, Олег Самойлов <splarv(at)ya(dot)ru>, pgsql-bugs(at)lists(dot)postgresql(dot)org, Álvaro Herrera <alvherre(at)kurilemu(dot)de> |
| Subject: | Re: basic_archive lost archive_directory |
| Date: | 2026-02-26 23:18:09 |
| Message-ID: | CAHGQGwFE4C6sn=X1o_Lzoyao1AdnpB2PVdjstT2TODppzPXHVw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Wed, Feb 25, 2026 at 2:34 AM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>
> On Tue, Feb 24, 2026 at 01:28:50PM +0900, Fujii Masao wrote:
> > I agree with removing the check from the GUC check hook. My only concern is
> > that simply removing it (rather than relocating it) changes the error message
> > users see when archive_directory is misconfigured, which may make
> > troubleshooting WAL archiving failures slightly harder.
> >
> > [Current]
> > WARNING: invalid value for parameter
> > "basic_archive.archive_directory": "not_exists"
> > DETAIL: Specified archive directory does not exist.
> >
> > [With the patch]
> > ERROR: could not create file
> > "not_exists/archtemp.00000001000000000000000E.80107.1771905339058": No
> > such file or directory
> >
> > One option would be to perform the check in check_configured_cb(),
> > but as you noted, that would add an extra stat() call for each WAL archiving.
> > If that overhead is unacceptable, another approach would be to wrap
> > copy_file() in basic_archive_file() with PG_TRY() / PG_CATCH(). On error,
> > we could stat() the archive directory and report a clearer reason if it does
> > not exist.
> >
> > That said, if users are generally fine with the "could not create file" error,
> > I'm ok with the proposed patch (i.e., just removing the check).
>
> I think it's fine as-is. If something is wrong with the error message,
> IMHO we should fix the error message. Adding extra stat() calls to try to
> give a nicer message might work most of the time, but there are still race
> conditions where users will see the original one. But in any case, I
> believe the current message style is used in many places, so I don't see a
> strong reason to do anything different here.
Ok, so since I seem to be the only one with some reservations about
the message, I'm fine with proceeding with the proposed change.
Regards,
--
Fujii Masao
| From | Date | Subject | |
|---|---|---|---|
| Next Message | surya poondla | 2026-02-26 23:55:43 | Re: BUG #19382: Server crash at __nss_database_lookup |
| Previous Message | Tom Lane | 2026-02-26 18:27:10 | Re: pg_get_viewdef() produces non-round-trippable SQL for views with USING join on mismatched integer types |