From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Luca Ferrari <fluca1978(at)gmail(dot)com> |
Cc: | pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: primary_conninfo and restore_command ? |
Date: | 2022-03-10 14:04:46 |
Message-ID: | 20220310140446.hwg6afcociudkcu7@jrouhaud |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi,
On Thu, Mar 10, 2022 at 02:51:16PM +0100, Luca Ferrari wrote:
> a friend of mine has shown to me a "strange" configuration of its
> physical replication server (13): he has both primary_conninfo and
> primary_slot_name, with replication slots active when queried on the
> master. So far so good, but in the configuration he has also
> restore_command to restore archived WALs from a centralized location.
> Does this make sense?
> Because if the replica cannot connect to the master, it will not start
> at all (so I guess no restore_command will be executed). On the other
> hand if the replica can connect to the primary the WALs will be
> shipped by means of streaming.
> Am I missing something?
We do have max_slot_wal_keep_size, and otherwise users could drop/create the
slot while the standby is shutdown if the situation is really bad, so it seems
sensible to me.
From | Date | Subject | |
---|---|---|---|
Next Message | Dominique Devienne | 2022-03-10 14:09:58 | PQresultMemorySize of ResultSet larger than expected |
Previous Message | Luca Ferrari | 2022-03-10 13:51:16 | primary_conninfo and restore_command ? |