Re: recovery_command has precedence over phisical slots?
От | Laurenz Albe |
---|---|
Тема | Re: recovery_command has precedence over phisical slots? |
Дата | |
Msg-id | 9a0bada8c474c73fa65f7a07e37c1ce9482686a5.camel@cybertec.at обсуждение исходный текст |
Ответ на | recovery_command has precedence over phisical slots? (Giovanni Biscontini <biscontini.g@es2000.it>) |
Список | pgsql-general |
On Fri, 2022-08-19 at 16:54 +0200, Giovanni Biscontini wrote: > Hello everyone, > I'm experiencing a behaviour I don't really understand if is a misconfiguration or a wanted behaviour: > 1) I set up a primary server (a.k.a. db1) with and archive_command to a storage > 2) I set up a replica (a.k.a. db2) that created a slot named as slot_2 and that has the recovery_command set to read archivedwal on the storage. > If I shutdown replica db2 during a pgbench I see the safe_wal_size queried from pg_replication_slots on the primary decreaseto a certain amount but still in the max_slot_wal_kepp_size window: even > if I restart the replica db2 before the slot_state changes to unreserved or lost I see that the replica gets needed walsfrom the storage using recovery_command but doesn't use slot on primary. > Only if I comment the recovery command on the .conf of the replica then it uses slot. > If this is a wanted behaviour I can't understand the need of slots on primary. This is normal behavior and is no problem. After the standby has caught up using "restore_command", it will connection to the primary as defined in "primary_conninfo" and stream WAL from there. Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com
В списке pgsql-general по дате отправления: