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 1vpqG3-00HDhv-1O for pgsql-bugs@arkaria.postgresql.org; Tue, 10 Feb 2026 16:06:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vpqG2-00G85U-1h for pgsql-bugs@arkaria.postgresql.org; Tue, 10 Feb 2026 16:06:34 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vpqG2-00G85M-0t for pgsql-bugs@lists.postgresql.org; Tue, 10 Feb 2026 16:06:34 +0000 Received: from mail-oa1-x2c.google.com ([2001:4860:4864:20::2c]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vpqG0-00000001T9S-0tCP for pgsql-bugs@lists.postgresql.org; Tue, 10 Feb 2026 16:06:32 +0000 Received: by mail-oa1-x2c.google.com with SMTP id 586e51a60fabf-40438380b88so606106fac.3 for ; Tue, 10 Feb 2026 08:06:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770739589; x=1771344389; darn=lists.postgresql.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=NSa0ibbRKLuNtipap4NWqyTAw991vcDetjExNzflXoE=; b=ZdsbLr5tV2fnegwfzpxgp+K2+Wq6SontCrftdaB/ufgsGBQxYKWroPXXzAT2eA1FoQ zU/6XbMUbzsfLjcdcUKK0jFfRpVN95nYaTDG7tLokwvrMETdmskejZANpv/GRETB+B7g 4X8xPsRDgAPyQS0iP40jFPxEg1FkJMuLL4/5o+m4dlVHEYcBOnLCGvQnozERP1xx+7QC PMKt4Uw3AnV+fO7K6P8URVodMWN5BPA7YZUV3DBkHTKzS+D0hy72M12IsHWwU+M7qFCB ha2Wr9MfZ8WV/fQCNnnJGHWSHCsh9pCC0q/sXF2BifIs1dVg121ayJmsfmnfgJgaz9pd axsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770739589; x=1771344389; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=NSa0ibbRKLuNtipap4NWqyTAw991vcDetjExNzflXoE=; b=Wu0Yk/1n3rFctuUxVgQy2f/yu8zl13nti/5UQN+BuCHn3DOgjmepYIXt3uq1vAMRHT ht3omEQ4X3imjIBeLIuP3OLCoNejlAb8jPAsT7zJpdXYVpgrs8cCLir7ykoJPOprV0Ia pWjkXfQlIz6ksO/REq43M0i+Uy4neLhCaPxiZ5hgU8jvl20vhk0+NVgoP1o4PbUFgLck joTitqPY+s2lO9/UCoUp6EI+XHncyoFZxRKahb612kuvJJkU03NkSw6MJiikjQThLtLh M0jlssWNwqeC+R56EQ9PLHy/Ig0LhGag/pPh/OGJZ8AOYgdrih+HrJ09NPNBc8oHsHQ2 14jA== X-Forwarded-Encrypted: i=1; AJvYcCXKIWe0Zig4yPrAJ9sUkP1SfSKIGp7bgXDPCkmqRZNHf6/AzpCe4Qk2CoWLaQKx4e7WgrprhluQks/z@lists.postgresql.org X-Gm-Message-State: AOJu0Yz0IHNlWHHZ58h8hT98kJ+vT91uvXK1r6b6FYoreLLre2Zh4sqh Kbo+C6parUBtV/yBbKOSTTx2AKuMKae/LdeWVCtPHnL09kvJtHhmmXjP X-Gm-Gg: AZuq6aL483dgFjkNFyVVE2UI0Z580tsE/giz+ssvfLu1gVY+prLxOReiEsblCmnTtOR /Wvv+ElOjANvzbbHbuweSVC4lCSncOzmomK/qoiHsiX5mIb3fmzdNDlzy/bl4Cx6G88HB8D3DS8 rldeqYb7W1L6ugeZXpYMO+RMWxObEmo21anadSRiDyb17jVIZuK91Q+9LWhlfqHgTf+61RBGgff JcZ5r6SQ0PNwipEYeBbzVI19HnYrWPw71WWQracJ2CJPgRT05YguhkjdEdpwWN4GuCPDcXLMUcL C5Vp6AsvJjZnX0ya+ZRGB0wsfVuEim9nXjmQ2gKlOovwfSS1Q4AWrB7sWPi0IYn9GdzVSP8pdjM 2ae7ILFHziNhaiLztmyaleo3YweBmdReIzxQLtKGiCMtDpKfB/NWif1CmBGOMuxLD+tq64flIKw 88hhblduTCS14h74aNI743tEaIcKqa+PaFBvdgMkLNKSKE0b5uOc94h8mlANEWjSfdn41ip+8hG bXdjfNMWKedt2ew X-Received: by 2002:a05:6871:4e96:b0:404:396d:8bc0 with SMTP id 586e51a60fabf-40a96d9b1fbmr7190564fac.18.1770739588261; Tue, 10 Feb 2026 08:06:28 -0800 (PST) Received: from nathan (162-195-168-172.lightspeed.stlsmo.sbcglobal.net. [162.195.168.172]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-40a9964b304sm10239709fac.11.2026.02.10.08.06.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Feb 2026 08:06:27 -0800 (PST) Date: Tue, 10 Feb 2026 10:06:25 -0600 From: Nathan Bossart To: Fujii Masao Cc: Sergei Kornilov , =?utf-8?B?0J7Qu9C10LMg0KHQsNC80L7QudC70L7Qsg==?= , pgsql-bugs@lists.postgresql.org, =?utf-8?Q?=C3=81lvaro?= Herrera Subject: Re: basic_archive lost archive_directory Message-ID: References: <202601301728.sfkizrto3t5i@alvherre.pgsql> <9b9341b0-942e-4d34-b94f-92bd918fad04@ya.ru> <1317421770387925@cea5cfd9-50d3-4d85-a924-a7cc75f8f215> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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 configuration > 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 that really shouldn't change as long as the GUC's value stays the same. In practice, the check callback is mostly meant to ensure the user hasn't temporarily halted archiving, as per the following note in basic_archive's documentation: The default is an empty string, which effectively halts WAL archiving, but if archive_mode is enabled, the server will accumulate WAL segment files in the expectation that a value will soon be provided. Furthermore, fixing this problem in basic_archive doesn't fix it for other archive modules that use GUC check hooks. I think it should be fixed more generally, perhaps by bumping up the log level in the archiver when the GUC's prefix matches the archive_library. 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. basic_archive must already be written to handle the archive directory disappearing at any moment, so we should be able to rely on it without the extra stat(). -- nathan