Thanks for your feedback
> How would you know which part of WAL is needed for any specific
replication slot?
change are captured for each published table and written twice, once in
the current wal and once in the slot-specific wal
> How would you handle multiple replications
for the same table
add
## Fabrice Chapuis (fabrice636...@gmail.com):
> From a conceptual point of view I think that specific wals per subscription
> should be used and stored in the pg_replslot folder in order to avoid
> working directly on the wals of the instance.
> What do you think about this proposal?
I think that
Thanks Christoph for your message.
Now I understand why the wals are preserved if logical replication is
configured and enabled. The problem is that when a large volume of data is
loaded into a database, for example during a pg_restore, the wal sender
process associated with the logical replication
Hi,
## Fabrice Chapuis (fabrice636...@gmail.com):
> 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?
There you have i
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 t39409 1EE2/4900
reservedf
barman_be physical f t39434 1EE
## Fabrice Chapuis (fabrice636...@gmail.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 datab
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
s
