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.94.2) (envelope-from ) id 1qlow3-004VAD-On for pgsql-hackers@arkaria.postgresql.org; Thu, 28 Sep 2023 11:11:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qlow2-00CCxa-6d for pgsql-hackers@arkaria.postgresql.org; Thu, 28 Sep 2023 11:11:58 +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.94.2) (envelope-from ) id 1qlow1-00CCxN-N6 for pgsql-hackers@lists.postgresql.org; Thu, 28 Sep 2023 11:11:57 +0000 Received: from mail-oa1-x35.google.com ([2001:4860:4864:20::35]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qlovy-0076Vj-99 for pgsql-hackers@lists.postgresql.org; Thu, 28 Sep 2023 11:11:56 +0000 Received: by mail-oa1-x35.google.com with SMTP id 586e51a60fabf-1dd6128352cso733283fac.0 for ; Thu, 28 Sep 2023 04:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695899513; x=1696504313; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=3jPQ4wycB4V4K+N52oVn5m5nSI47tuksXKG/HR60GkY=; b=mvue+RVLDPfrvw6GEahhM81NMrVLR5gnql6z5AvDgjGTeXwBCDCYugGjllsvkN8w7f bOIUV/4dqjNHVeo7T54y7MOeO+vesWlUkt5RxMhTfh0YskiGADKonI45h9+0gjDYB6Zw TAxrc72CWOwhNt2tiMst57NBGR/phxBAf/XL8dh7YOa4e3e7EbEJJBoKDzG+MDKQ2A5z +QxZwm2crsLWZbzEG3xn+bWsuv3Q2t3JWxUFs1SLw5cjrzVOeqi2SBwC4Lmsh/Oe/aHr cYnmjF/Xr+R+ofNZIyVnBHVnxRg9DBxsYdCpdZKzAd/1L/jaq0Jh7zr9lKF43n3X3c1x H++Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695899513; x=1696504313; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=3jPQ4wycB4V4K+N52oVn5m5nSI47tuksXKG/HR60GkY=; b=iD4kchn65BKxZzbaZVxYa57m6Crnw/dRn1UOtlYpkOq698QeFlV5jvWPqxsbJXgB37 5ExUz1so2PzSQwohcINakNuCA2KaZlqspOTQU4tqXmXCDV0NO6EuCpry0/t/f8PPn63M UA/RaiaiVunjZm5+dRVI3g3s2RZBsHFsbGc+pV3ivZbKx15zwfSqQlQ9On5xBLxriW/P qG2hprrQccLT0tJFBXmGLABpEzKZjDV0sLyME1oLTCKgDJx/KaVxuHFHCQ19o9pSoUJo smQ/57/HTIyO7JSm/fwVszosr7tYDPyYwdOVj7xj3q5tp7oIFGmvzHiVAYmmzFR3+N2N bVRA== X-Gm-Message-State: AOJu0YzKT0v0HtCfeBmzty71QH6vrJBNgC8JriJeDTQN2gki9ZF0Yw1L b6zRUx2ED4YiDn/BotDYT9EvLs8bmEF0aYZkbDY/4ovc2uU= X-Google-Smtp-Source: AGHT+IEIe1Jpz/yYMXh7SV6EMgSuTKyS4c2R8AI4oeIOXcKLQO6+37TwgtGBxST+NpiWBqJKu/FZyNs1aZTov3tFVoo= X-Received: by 2002:a05:6870:561e:b0:1d5:53c0:c1fe with SMTP id m30-20020a056870561e00b001d553c0c1femr979197oao.3.1695899512000; Thu, 28 Sep 2023 04:11:52 -0700 (PDT) MIME-Version: 1.0 From: Fabrice Chapuis Date: Thu, 28 Sep 2023 13:11:41 +0200 Message-ID: Subject: wal recycling problem To: PostgreSQL Hackers Content-Type: multipart/alternative; boundary="000000000000fcd57e0606695f71" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000fcd57e0606695f71 Content-Type: text/plain; charset="UTF-8" Hello, I have a question about the automatic removal of unused WAL files. When loading data with pg_restore (200Gb) we noticed that a lot of WALs files are generated and they are not purged automatically nor recycled despite frequent checkpoints, then pg_wal folder (150Gb) fill and become out of space. We have a cluster of 2 members (1 primary and 1 standby) with Postgres version 14.9 and 2 barman server, slots are only configured for barman, barman is version 3.7. The archive command is desactivated (archive_command=':') I use pg_archivecleanup (with the wal file generated from the last checkpoint in parameter) to remove files manually before the limit of 150Gb so that the restore can terminate. Why does postgres do not this cleanup automatically, which part of the code is responsible for removing or recycling the wals? Thanks for your help Fabrice --000000000000fcd57e0606695f71 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I ha= ve a question about the automatic removal of unused WAL files. When loading= data with pg_restore (200Gb) we noticed that a lot of WALs files are gener= ated and they are not purged automatically nor recycled despite frequent ch= eckpoints, then pg_wal folder (150Gb) fill and become out of space.
We have a cluster of 2 members (1 primary and 1 standby) with Postgres v= ersion 14.9 and 2 barman server, slots are only configured for barman, barm= an is version 3.7.
The archive command is desactivated (archive_c= ommand=3D':')
I use pg_archivecleanup (with the wal file = generated from the last checkpoint in parameter) to remove files manually b= efore the limit of 150Gb so that the restore can terminate.

<= /div>
Why does postgres do not this cleanup automatically, which part o= f the code is responsible for removing or recycling the wals?
Thanks for your help

Fabrice
--000000000000fcd57e0606695f71--