Re: Configuring synchronous replication

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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 the standby setup?

- service level and current weight and any other knob that comes from
the standby are changed on the fly by the master if that 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 changed on 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 transient unavailability

- 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