Heikki Linnakangas <heikki.linnakan...@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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
