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 1voLU8-001mMi-24 for pgsql-bugs@arkaria.postgresql.org; Fri, 06 Feb 2026 13:02:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1voLU7-003sgV-1Q for pgsql-bugs@arkaria.postgresql.org; Fri, 06 Feb 2026 13:02:55 +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 1voLU7-003sgN-09 for pgsql-bugs@lists.postgresql.org; Fri, 06 Feb 2026 13:02:55 +0000 Received: from forward502b.mail.yandex.net ([2a02:6b8:c02:900:1:45:d181:d502]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1voLU4-00000001MeY-0kIr for pgsql-bugs@lists.postgresql.org; Fri, 06 Feb 2026 13:02:54 +0000 Received: from mail-nwsmtp-smtp-production-main-70.sas.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-70.sas.yp-c.yandex.net [IPv6:2a02:6b8:c11:e97:0:640:f294:0]) by forward502b.mail.yandex.net (Yandex) with ESMTPS id 85F8180DC1; Fri, 06 Feb 2026 16:02:50 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-70.sas.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id n2O49t2GOqM0-RfSPj49p; Fri, 06 Feb 2026 16:02:50 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ya.ru; s=mail; t=1770382970; bh=Z0tSGLNxsHLxOMuQ0C78qFSxZzhsaTSkkMYi7tGh49s=; h=In-Reply-To:Cc:Date:References:To:Subject:Message-ID:From; b=ZVweNyY/APi8UVURvygGcWzM8vfFUTp8pk68Ccrdn1EdQVUV65PlNYmW4zbro54X9 YIAdzSABpaMswV0yL+l/WNddNCABhPTE7kiiMtVLuqOGwf8PJNdMf1jVfzsYzCicGD oIXMVpUNM95dDDBGXNnO7xRwwT8LhtRZf1G4btQQ= Authentication-Results: mail-nwsmtp-smtp-production-main-70.sas.yp-c.yandex.net; dkim=pass header.i=@ya.ru Content-Type: multipart/alternative; boundary="------------EA0EHKvHrSqnWTqLcPkxXVTN" Message-ID: <9b9341b0-942e-4d34-b94f-92bd918fad04@ya.ru> Date: Fri, 6 Feb 2026 16:02:48 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: basic_archive lost archive_directory To: =?UTF-8?Q?=C3=81lvaro_Herrera?= Cc: "pgsql-bugs@lists.postgresql.org" References: <202601301728.sfkizrto3t5i@alvherre.pgsql> Content-Language: ru, en-US From: =?UTF-8?B?0J7Qu9C10LMg0KHQsNC80L7QudC70L7Qsg==?= In-Reply-To: <202601301728.sfkizrto3t5i@alvherre.pgsql> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------EA0EHKvHrSqnWTqLcPkxXVTN Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 31.01.2026 19:08, Álvaro Herrera пишет: > On 2026-Jan-29, Олег Самойлов wrote: > >> 2026-01-23 18:46:49.970 MSK,,,12085,,697397e9.2f35,1,,2026-01-23 18:46:49 >> MSK,,0,WARNING,22023,"invalid value for parameter >> ""basic_archive.archive_directory"": ""/mnt/ocean/postgres/stars/ >> WAL""","Specified archive directory does not exist.",,,,,,,,"","archiver",,0 > Most likely, the NFS mount was lost for some reason. Did you check the > kernel logs? Did you ask your colleagues if they unmounted the > filesystem for laughs? Did you search for any funny logs on the NFS > server side? May be this is the reason for the first message and this is not a bug. This can be with NFS. >> 2026-01-23 18:57:23.589 MSK,,,12085,,697397e9.2f35,2,,2026-01-23 18:46:49 >> MSK,,0,WARNING,01000,"""archive_mode"" enabled, yet archiving is not >> configured","basic_archive.archive_directory is not >> set.",,,,,,,,"","archiver",,0 >> And directory existed and it has old WAL files (before error raised). >> The basic_archive is unstable, but I don't know how to repeat this. > It's difficult to believe that it was basic_archive's fault; it's just > giving you whatever the kernel reported to a stat() call for the > directory. The bug is here. basic_archive lost the value and was empty. But show all; show that the value is. --------------EA0EHKvHrSqnWTqLcPkxXVTN Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


31.01.2026 19:08, Álvaro Herrera пишет:
On 2026-Jan-29, Олег Самойлов wrote:

2026-01-23 18:46:49.970 MSK,,,12085,,697397e9.2f35,1,,2026-01-23 18:46:49
MSK,,0,WARNING,22023,"invalid value for parameter
""basic_archive.archive_directory"": ""/mnt/ocean/postgres/stars/
WAL""","Specified archive directory does not exist.",,,,,,,,"","archiver",,0

      
Most likely, the NFS mount was lost for some reason.  Did you check the
kernel logs?  Did you ask your colleagues if they unmounted the
filesystem for laughs?  Did you search for any funny logs on the NFS
server side?

May be this is the reason for the first message and this is not a bug. This can be with NFS.

2026-01-23 18:57:23.589 MSK,,,12085,,697397e9.2f35,2,,2026-01-23 18:46:49
MSK,,0,WARNING,01000,"""archive_mode"" enabled, yet archiving is not
configured","basic_archive.archive_directory is not
set.",,,,,,,,"","archiver",,0
And directory existed and it has old WAL files (before error raised).
The basic_archive is unstable, but I don't know how to repeat this.
It's difficult to believe that it was basic_archive's fault; it's just
giving you whatever the kernel reported to a stat() call for the
directory.
The bug is here. basic_archive lost the value and was empty. But show all; show that the value is. --------------EA0EHKvHrSqnWTqLcPkxXVTN--