Gregory Stark wrote:
b) vacuum on the server which cleans up a tuple the slave has in scope has to block WAL reply on the slave (which I suppose defeats the purpose of having a live standby for users concerned more with fail-over latency).
One problem with this, BTW, is that if there's a continuous stream of medium-length transaction in the slave, each new snapshot taken will prevent progress in the WAL replay, so the WAL replay will advance in "baby steps", and can fall behind indefinitely. As soon as there's a moment that there's no active snapshot, it can catch up, but if the slave is seriously busy, that might never happen.
Nevertheless, I think it's a much nicer approach. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
