Wal streaming
Hi,
New to the list. If I’m Using streaming archiving with repmgr, and streaming archiving with barman, do I still need to maintain my archive command, and have processes in place to delete archived wals periodically? Or are they in effect defunct due to wal retention policies within Postgres?
Regards
Andrew
Sent from my iPhone
On 11/25/25 05:46, Andrew wrote:
Hi,
New to the list. If I’m Using streaming archiving with repmgr, and streaming archiving with barman, do I still need to maintain my archive command, and have processes in place to delete archived wals periodically? Or are they in effect defunct due to wal retention policies within Postgres?
You are going to need to expand on this as it is unclear to me what your
processes are.
1) What is the repmgr setup for streaming?
2) What is the Barman setup for streaming?
3) What locations are 1 & 2 streaming to?
4) What is the process you have in place now to prune the archives?
5) What are the Postgres version you are working with?
Regards
AndrewSent from my iPhone
--
Adrian Klaver
adrian.klaver@aklaver.com
Hi,
I’m using Postgres 17 and the latest versions of repmgr and barman
1. I’m replicating my database to another node using streaming replication. wal_level=replica, hot_standby=on.
2. I’ve 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’s 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 using streaming?
Regards
Andrew
Sent from my iPhone
Show quoted text
On 25 Nov 2025, at 16:54, Adrian Klaver <adrian.klaver@aklaver.com> wrote:
On 11/25/25 05:46, Andrew wrote:
Hi,
New to the list. If I’m Using streaming archiving with repmgr, and streaming archiving with barman, do I still need to maintain my archive command, and have processes in place to delete archived wals periodically? Or are they in effect defunct due to wal retention policies within Postgres?You are going to need to expand on this as it is unclear to me what your processes are.
1) What is the repmgr setup for streaming?
2) What is the Barman setup for streaming?
3) What locations are 1 & 2 streaming to?
4) What is the process you have in place now to prune the archives?
5) What are the Postgres version you are working with?
Regards
Andrew
Sent from my iPhone--
Adrian Klaver
adrian.klaver@aklaver.com
On 11/25/25 23:27, Andrew wrote:
Hi,
I’m using Postgres 17 and the latest versions of repmgr and barman
1. I’m replicating my database to another node using streaming replication. wal_level=replica, hot_standby=on.
2. I’ve 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’s 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 using 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.
Regards
Andrew
Sent from my iPhone
--
Adrian Klaver
adrian.klaver@aklaver.com
On Wed, Nov 26, 2025 at 2:26 PM Adrian Klaver <adrian.klaver@aklaver.com>
wrote:
On 11/25/25 23:27, Andrew wrote:
Hi,
I’m using Postgres 17 and the latest versions of repmgr and barman
1. I’m replicating my database to another node using streaming
replication. wal_level=replica, hot_standby=on.
2. I’ve 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’s 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 using
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).
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!