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
