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 1vOLTX-003hXu-2d for pgsql-general@arkaria.postgresql.org; Wed, 26 Nov 2025 19:46:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vOLTU-001FQM-35 for pgsql-general@arkaria.postgresql.org; Wed, 26 Nov 2025 19:46:49 +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 1vOLTU-001FQE-1p for pgsql-general@lists.postgresql.org; Wed, 26 Nov 2025 19:46:48 +0000 Received: from mail-ot1-x334.google.com ([2607:f8b0:4864:20::334]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vOLTS-001f1P-36 for pgsql-general@lists.postgresql.org; Wed, 26 Nov 2025 19:46:48 +0000 Received: by mail-ot1-x334.google.com with SMTP id 46e09a7af769-7c75fc222c3so91444a34.0 for ; Wed, 26 Nov 2025 11:46:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764186404; x=1764791204; darn=lists.postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=0+BQcAh5Fn/u18LPZXc8JlS5hQTztqMSG/O79oZMaO8=; b=gs+y7WzVCp5y0KoKHrr6vsoKQ4w1BZrBfGNsWVxkljmkTNHfhDD9jgD0n0u0M2rOi9 y7Ozzx4eKFRkt+LwkStN6BcNW89shwUH39Zm34S9+tKmNWqVy0Vx15vPvolcOCno3bId sOhICYUbFCLxDaQLLISIKDit4A64MduRdhpw346TLQyjHkfgO2TFSVuDpvjNBt4CBYdc KXfxaEoG3h1gDxPlGSxOByZHXEt804mPf1+S1QnisJND2L+loOIgn0lpjtm8lGqJq5Yv mSCSo6fsp/bNXf7Jd/8oA+UBj2pYsA6btoqKuKY9q1ofiOj5LSctShAgffg+ZtOeQR5Z l72w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764186404; x=1764791204; h=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=0+BQcAh5Fn/u18LPZXc8JlS5hQTztqMSG/O79oZMaO8=; b=HYh9mV8Xw7CYzW2KgTI2IcHQqtIFlXtNTIXYIaNX+1j89aC3apVouvfqP0KiLrC+wO LihvEgNPRx/qf5ZhQnETi17eqcGTKVaiclGOx98NRrXY4T08rXPQpJEMQU+BnOOmavx6 Rs/nqdNnlCZKcA5ukPkB/0hbbgxBjsFSS04rV2IDl6ANktL1NqU8Seo2kNsTtRgBJDG2 JWCQ3X8SEiBm4OWyEOwHrKjTFbwJLQT5jZHQ/Dc/Lq3PbS7Y7N1cq6poKQwLyZ6sBEXw 0FBIndMpxvTDuXZ77TZDpkbOWUoIQC68ZUAyc/UXIb0aAH65xrDZH1GQinYYXbmEqBgQ kAHw== X-Gm-Message-State: AOJu0YyfIKGIVC1UNu2ARsZP5L6/nIQs4k5ShoG62x2H7QmSnjdve1zz v61oA1Jov36DhFJoPsQSh3NkzW/sXchY3L/J69JnCSgxaAl1SaPS8XUZ58Hp9V6XgkChpicj6N6 SBWFPtb2fp0V8FA4IOAnsPqe/9QIvSWUS7A== X-Gm-Gg: ASbGncuyMatrtetDaxqcHLqgXhfN0DfZR/2PXVPY6Ofm8M1i0f84Kwg2brU0myD7ENH BPi9foWfBuaDS71m8rdCdfqP5j2g3UmisQcA4iJaGHHn44Sk5kZ0wqgMK1P9aBkxLNBh3okibf7 7Lc1zD7EhW3hmDDr/e4nels0ZQGE5wPDkfW6XOPw6oH9pxbISPgiP2t+Gjj6eOhq1EsXvtdIFOP aQolSKpRljrolpPC89TU96Nc+10JRVktWJ4HhbUkvo/SlFri20+wxv3uC664KoOUl28a346 X-Google-Smtp-Source: AGHT+IFv/dxgTiwce1Wdcd6bJJ6JexgBhzxp5uuVK7mV48NzListkQkNwI2lJ5+/X+z4bqebUTi0bb1/RHgveTHm1ys= X-Received: by 2002:a05:6808:218a:b0:450:b8a2:47a5 with SMTP id 5614622812f47-45115b42ba5mr9086146b6e.67.1764186404302; Wed, 26 Nov 2025 11:46:44 -0800 (PST) MIME-Version: 1.0 References: <4b91a533-b2b7-42fe-bfb7-d92d56c6c1c1@aklaver.com> <95c0ba97-f427-4a4b-8e18-67c1ba3a60fd@aklaver.com> In-Reply-To: <95c0ba97-f427-4a4b-8e18-67c1ba3a60fd@aklaver.com> From: Ron Johnson Date: Wed, 26 Nov 2025 14:46:33 -0500 X-Gm-Features: AWmQ_bnA8is8emAXdd7LoSsKGWKWNqvgW9b1u5Lf5RmDM8fP8x3yvOd495w3Pjw Message-ID: Subject: Re: Wal streaming To: "pgsql-generallists.postgresql.org" Content-Type: multipart/alternative; boundary="000000000000f232d4064484a7d2" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000f232d4064484a7d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 26, 2025 at 2:26=E2=80=AFPM Adrian Klaver wrote: > On 11/25/25 23:27, Andrew wrote: > > Hi, > > > > I=E2=80=99m using Postgres 17 and the latest versions of repmgr and bar= man > > > > 1. I=E2=80=99m replicating my database to another node using streaming > replication. wal_level=3Dreplica, hot_standby=3Don. > > 2. I=E2=80=99ve got barman running on the primary node locally and have= setup > the barman config for streaming replication using streaming archiver and > backup method Postgres. Previous to this I was using the archive and > restore commands in postgresql.conf to use barman-wal-archive|restore to > copy the wal files to barman=E2=80=99s wal folder. > > 3. Barman is on node 1 where the primary is running. The replica > database used by repmgr is on node 2. > > 4. My archive command is still configured to use barman-wal-archive > despite having moved to a streaming replication method in barman. > > > > So my question is, can I disable the archive command now that I am usin= g > streaming? > > I am not going to straight up say you can disable the archive command as > I will not be the one that has to bear the consequences. > > What I will say: > > 1) Have you tested that the Barman, repmgr setups work to do a recovery? > > 2) Are the two archive processes(streaming replication, > barman-wal-archive) going to different locations? > > 3) There is also the question of whether the two archive methods are in > sync. In other words would you get the same restore if used either at > some point in time? > > My personal opinion is you would be best served by having only one > tested process working. > I wonder if a non-streaming backup program like pgbackrest would simplify things. It would eliminate one stream, and remove the need to manage the wal archive (since pgbr does all that for you in its own separate repository). --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --000000000000f232d4064484a7d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 26, 2025 at 2:26=E2=80=AFPM A= drian Klaver <adrian.klaver= @aklaver.com> wrote:
On 11/25/25 23:27,= Andrew wrote:
> Hi,
>
> I=E2=80=99m using Postgres 17 and the latest versions of repmgr and ba= rman
>
> 1. I=E2=80=99m replicating my database to another node using streaming= replication. wal_level=3Dreplica, hot_standby=3Don.
> 2. I=E2=80=99ve got barman running on the primary node locally and hav= e setup the barman config for streaming replication using streaming archive= r and backup method Postgres. Previous to this I was using the archive and = restore commands in postgresql.conf to use barman-wal-archive|restore to co= py the wal files to barman=E2=80=99s wal folder.
> 3. Barman is on node 1 where the primary is running. The replica datab= ase used by repmgr is on node 2.
> 4. My archive command is still configured to use barman-wal-archive de= spite having moved to a streaming replication method in barman.
>
> So my question is, can I disable the archive command now that I am usi= ng streaming?

I am not going to straight up say you can disable the archive command as I will not be the one that has to bear the consequences.

What I will say:

1) Have you tested that the Barman, repmgr setups work to do a recovery?
2) Are the two archive processes(streaming replication,
barman-wal-archive) going to different locations?

3) There is also the question of whether the two archive methods are in sync. In other words would you get the same restore if used either at
some point in time?

My personal opinion is you would be best served by having only one
tested process working.
=C2=A0
I wonder if a= non-streaming backup program like pgbackrest would simplify things.=C2=A0 = It would eliminate one stream, and remove the need to manage the wal archiv= e (since pgbr does all that for you in its own separate repository).
<= /div>

--
Death to <Reda= cted>, and butter sauce.
Don't boil me, I'm still alive.
=
<Redacted> lobster!
--000000000000f232d4064484a7d2--