Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> If you want the behavior where the master doesn't acknowledge a commit to
> the client until the standby (or all standbys, or one of them etc.)
> acknowledges it, even if the standby is not currently connected, the master
> needs to know what standby servers exist. *That's* why synchronous
> replication needs a list of standby servers in the master.
And this list can be maintained in a semi-automatic fashion:
- adding to the list is done by the master as soon as a standby connects maybe we need to add a notion of "fqdn" in
thestandby setup?
- service level and current weight and any other knob that comes from the standby are changed on the fly by the master
ifthat changes on the standby (default async, 1, but SIGHUP please)
- current standby position (LSN for recv, fsync and replayed) of the standby, as received in the "feedback loop" are
changedon the fly by the master
- removing a standby has to be done manually, using an admin function that's the only way to sort out permanent vs
transientunavailability
- checking the current values in this list is done on the master by using some system view based on a SRF, as already
said
Regards,
--
dim