0

We have a primary and standby PostgreSQL v14 server setup with streaming replication using:

pg_basebackup -h primary-server -U repuser --checkpoint=fast -D /data/db/postgresql/14/main/ -R --slot=foo -C --port=5432

We have not changed any settings in postgresql.conf except listen_addresses.

The streaming replication is working, all data is immediately available on the standby but the primary server is filling up it's pg_wal/ directory non-stop until the disk is full and the server crashes.

It is my understanding that streaming replication does not work by the standby reading these "WAL" files in pg_wal/ and that pg_wal/ should only contain data not yet synched. IMHO this directory should automatically empty when all replicas are in synch.

As I mentioned no default settings were changed: archive_mode and archive_command are commented out.

  1. Does streaming replication depend on this pg_wal/ directory?
  2. What is the correct process for preventing unfettered growth of pg_wal/?
  3. Can I just switch archive_mode to off?

select * from pg_replication_slots; on the primary shows the slot foo of type physical and state reserved

  1. What does the slot foo do and can I delete it?

UPDATE: The slot foo is active and cannot be deleted.

1
  • "Can I just switch archive_mode to off?" It is off by default. If you can find some place where it has been switched on, then switch it back off.
    – jjanes
    Commented Dec 8, 2022 at 14:56

1 Answer 1

1

You have to configure

primary_slot_name = 'foo'

on the standby server, otherwise it will not use the replication slot, and the primary will keep the WAL indefinitely.

8
  • OK, this is weird - I havent configured primary_slot_name on the standby - it's commented out - but suddenly the pg_wal/ directory is NOT filling up. What is also weird is that primary_slot_name is not mentioned in any guide on streaming replication.
    – Marc
    Commented Dec 10, 2022 at 10:18
  • Also, your explanation implies that the standby would not "use" the slot - but replication is working fine. Could it be that when I ran pg_basebackup and provided a slot name that it is persisted somewhere else? It's not in postgresql.conf.
    – Marc
    Commented Dec 10, 2022 at 10:20
  • A replication slot is not necessary for replication. It is necessary for the primary to remember how much WAL it must retain in case the standby disconnects. As soon as you set primary_slot_name, the standby will make the primary move the slot ahead, so WAL on the primary can be removed. Commented Dec 10, 2022 at 15:01
  • OK, thank-you for the explanation. I guess the mystery now is: why is my primary server now clearing pg_wal/ nicely without a configured primary_slot_name on the standby?
    – Marc
    Commented Dec 12, 2022 at 7:07
  • Either you dropped the replication slot, or something moved it ahead, or you have reached max_slot_wal_keep_size. Commented Dec 12, 2022 at 7:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.