Re: basic_archive lost archive_directory

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

In response to

Responses

Browse pgsql-bugs by date

  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