Re: wal recycling problem

Yes, barman replication can keep up with primary, wals segments size are
under max_wal_size (24Gb in our configuration)

Here is pg_replication_slots view:

barman_ge physical f t 39409 1EE2/49000000
reserved f
barman_be physical f t 39434 1EE2/3D000000
reserved f

on the other hand there are 2 slots for logical replication which display
status extended. I don't understand why given that the confirmed_flush_lsn
field that is up to date. The restart_lsn remains frozen, for what reason?

pgoutput │ logical │ 2667915 │ db019a00 │ f │ t │ 1880162
│ │ 68512101 │ 1ECA/37C3F1B8 │ 1EE2/4D6BDCF8 │ extended │
│ f │
pgoutput │ logical │ 2668584 │ db038a00 │ f │ t │
363230 │ │ 68512101 │ 1ECA/37C3F1B8 │ 1EE2/4D6BDCF8 │
extended │ │ f │

Regards
Fabrice

On Thu, Sep 28, 2023 at 7:59 PM Christoph Moench-Tegeder <cmt(at)burggraben(dot)net>
wrote:

> ## Fabrice Chapuis (fabrice636861(at)gmail(dot)com):
>
> > 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 obvious question here is: can both of those barmans keep up with
> your database, or are you seeing WAL retention due to exactly these
> replication slots? (Check pg_replication_slots).
>
> Regards,
> Christoph
>
> --
> Spare Space
>