Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vuk2l-0048hF-0a for pgsql-bugs@arkaria.postgresql.org; Tue, 24 Feb 2026 04:29:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vuk2k-00GyE0-0X for pgsql-bugs@arkaria.postgresql.org; Tue, 24 Feb 2026 04:29:06 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vuk2j-00GyDs-30 for pgsql-bugs@lists.postgresql.org; Tue, 24 Feb 2026 04:29:05 +0000 Received: from mail-oo1-xc33.google.com ([2607:f8b0:4864:20::c33]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vuk2h-00000000ybL-08R4 for pgsql-bugs@lists.postgresql.org; Tue, 24 Feb 2026 04:29:05 +0000 Received: by mail-oo1-xc33.google.com with SMTP id 006d021491bc7-679b072ed3aso2645617eaf.1 for ; Mon, 23 Feb 2026 20:29:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771907342; cv=none; d=google.com; s=arc-20240605; b=gIhD5YLUdnvG/rkEwfvaQqGsdu3IDy6RnIlAM8I4Q37pbXAyZNqL8ZhKhItIqIEe60 5RzL9gtTvrAHUYCddU27t38U4U7WCYF2BF487jtJy0PBQ37YqYre0MDDY6ToPUBwYGPW M4mtYvIxoZPJhvHnlwQFEx3bvvz6xroZF75Xi31oHGRYDTFzLBQNN5XDdWCFk/cn9Rjs Swu+oKi8dO5g0MdanFtuA9W/q7DVO3fEzAAI3wsFfpdcBqw4UaWwcb5ALpSUA+35vccX PyHU8ZRsxlwryNz+Hu5EOwiZAOBansFhNk/MZkLUs9UkFjYOgEKAKtNcUkkoCGpm+0LW AUNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=xeJFZ7ZKYN90cC0VT0LPKZeuXRub8hvLuF2MlOa4vOs=; fh=hi0c49x/7q3UaKyFoQof5ICAzwXBq8oeCaY5Igw61kQ=; b=Pa9x63X7K36x5mSRaikwhqD6kRaT3s92k3cvPuDbZP7EWF59wPv4CranaoDXY+seoo CCm5afodJbTMdoyQGQT+cNLcCrVbLqdnNkgptNCNTQ7PXKkajetzuy605FZRWsqxsOq+ /CpvBCqX62bF4zTqN5EDIBUX1Rv7FDihjePX8JFi20vt1v6mbBMTyxCod9HTMP7+u8+b 4SIMZ6Wq/QTkkaWKrZpCGwSAS+rQETMBG7KGNInaQ1SSC9l0RV04DUZIIFdXfmq8YimI eqsJAfmW9Tq6Z7pQPgyvL4KAqjB6L5q/l264wWXz4Yr/gQdh5/NG1bM627seEcd6jjeE AhIw==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771907342; x=1772512142; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=xeJFZ7ZKYN90cC0VT0LPKZeuXRub8hvLuF2MlOa4vOs=; b=UrI2wZWI78KGSyInMNiq0RBdXFdgmNxKLMInPFyYc7KcUwTvGbvuJu/G7B7OBbuYPZ mSFWp2Yv7JTCHSwkfTFQy9zJJM9rXs0w2ddN0WFVu8Leg39Rb4Cf0tSz+rr/3HuFZXRQ NNERWyI+0/kJgjEYCYPr5t8vPzF4utfcZwYYhYJV1GpRaZJAebEUQSV680zJaXZQ4eBT TiT3mzlvgdOoAUbTkG/6gSHd32mKlNDOCNtpKS1KY51VQUM7IsNI2HsV7+zGhn6ORq4l tjAonySKhx2NureySyFExVlm5KfVbPg2NgCZ4vc3AEZ/GMMUXWQqkybLRZXmNJwCVr48 SZDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771907342; x=1772512142; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=xeJFZ7ZKYN90cC0VT0LPKZeuXRub8hvLuF2MlOa4vOs=; b=Fwn+CPfPoHkvxqiEIzSAxOaWUnuULWsfbMEIklBITvOs1gv+jhoIsA8hbxVW8JrEFo DcGHJxek208RSb/EfWUXjbhH4ACUG/s2f4jsqnlkTGyd76FdfH0X/+jBIHoG+EhWOPxg D8au0ah5cB714xeKFLBmVIyRsXxmCpthFRX70U1IUxm4YZatYizWIXCD+P+YUljgb7nx BZuS0/2RnFhQQog6N0Q4d3sTaxkeMmrzt09FygT5cRdEw+7U69UxJFHSto8xtai6in5p JSXODlW38OVxIxVlDmusIudNQIpx4KPpm/eX37YZmyGklAaid97bKhlw4uwShV14YdIc 3fxQ== X-Forwarded-Encrypted: i=1; AJvYcCWZrsV0rUxOR+DyXnZufztXfycxtXFSHZSPCZaXdQ93d3VnayH79D9+LzKToimEhABFfnzAd1hJ9KHO@lists.postgresql.org X-Gm-Message-State: AOJu0Yx1U674u4WE+ZB/v2QklMu6xbeATLPTdDSOchFFBG5SwpMnBRZk Daw11SEBTS5GpHWpAI6st95F81NhEkrnot0Gdc1Jcjz5ZAxkENe0HY5bXwkDWRRGh7oXCIlZkM0 KGjJSTJlfWjrd7cmW20FujR8x92Vr+Ks= X-Gm-Gg: AZuq6aLVGKTVpNiViGrqbYAP7MqpiPVM5adWqeuBCnjUF6kEZW2NInuUAiOXdWfMSxy EkrkUYJsab2/kvq8mqsbpJbr1GSj30TPYUbjVgBdwwI4UjmieK/O+HBfY/INltY6shBUE6IvPKz HaK7gdpxsBEshS9t5QmlXLILZnlMjyRL5bhH4nWe6+VutgGJRcEyKUooFA/VLqzLPxWxbvManDR FGEGDXchEpzy+DOj0yFNEFHckd2sytOwpmO54Mo+BPGoAbVN6j00dN9+zTmgEgyMR6q6yjy/Bia 58dusMLftnxyubXNNs0uXaVQx6/Kdovhd/lEusSeIw== X-Received: by 2002:a05:6820:1c96:b0:659:9a49:8f99 with SMTP id 006d021491bc7-679c42825a8mr5741896eaf.18.1771907342256; Mon, 23 Feb 2026 20:29:02 -0800 (PST) MIME-Version: 1.0 References: <202601301728.sfkizrto3t5i@alvherre.pgsql> <9b9341b0-942e-4d34-b94f-92bd918fad04@ya.ru> <1317421770387925@cea5cfd9-50d3-4d85-a924-a7cc75f8f215> In-Reply-To: From: Fujii Masao Date: Tue, 24 Feb 2026 13:28:50 +0900 X-Gm-Features: AaiRm51iXRsiHhFFdyS7Llzmkzq3bPFEfmVE9yempjZ1-qckD91L5dJ_g6Jwm24 Message-ID: Subject: Re: basic_archive lost archive_directory To: Nathan Bossart Cc: Sergei Kornilov , =?UTF-8?B?0J7Qu9C10LMg0KHQsNC80L7QudC70L7Qsg==?= , pgsql-bugs@lists.postgresql.org, =?UTF-8?Q?=C3=81lvaro_Herrera?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Feb 11, 2026 at 1:06=E2=80=AFAM Nathan Bossart wrote: > > On Tue, Feb 10, 2026 at 10:23:02AM +0900, Fujii Masao wrote: > > You're right if an invalid value for basic_archive.archive_directory is= detected > > at server startup. However, when the setting is changed and the configu= ration > > is reloaded, the default behavior does not emit an error log. > > Oh, I see. Even so, I don't think this problem is best fixed by moving > code from the GUC check hook to the archive module check callback. For > starters, since the archive module check callback is called for each file > to archive, this adds unnecessary overhead to repeatedly verify things th= at > really shouldn't change as long as the GUC's value stays the same. Yes, so if we had an archive module callback invoked just after ProcessConfigFile(), we could use it to check the archive directory only when needed. However, introducing a new callback isn't suitable for back branches. > I also want to push back a bit on the idea that basic_archive not working > when the directory is missing at startup is a bug. The documentation for > basic_archive clearly states that the directory must already exist. That > being said, I have no objection to making basic_archive more lenient or > even to back-patching such a change. As I mentioned upthread, IMHO we > should simply remove the existence check from the GUC check hook. 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 messa= ge 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 archivin= g. 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 doe= s not exist. That said, if users are generally fine with the "could not create file" err= or, I'm ok with the proposed patch (i.e., just removing the check). Regards, --=20 Fujii Masao