> I'd imagine that even if applying the WAL on the slave is blocked, it's
> still streamed from the master to the slave, and in case of failover the
> slave will fast-forward before starting up as the new master. Of course, if
> it has fallen 3 days behind because of a giant reporting query, it can take
> a while to replay all the WAL that has accumulated.
Yes, and meanwhile, any other queries that are running on that box are
seeing three-day old data as well.
In an ideal world, it would be nice if the slave could keep tuples
around even after they are dead and vacuumed on the master. Pushing
Xmin from the slave to the master creates the possibility of bloating
the master due to activity on the slave, which is not going to improve
reliability. OTOH, not pushing Xmin leads to several pathological
query behaviors on the slave: cancelled queries, inconsistent reads,
and falling way behind on WAL application. Either way, it seems to me
a massive and uncomfortable violation of the POLA.
If it were possible for tuples that had been vacuumed on the master to
stick around on the slave for as long as the slave still needed them,
then you'd have the best of both worlds, but I have a feeling
someone's going to say that that's just about impossible to implement.Against that, all I can say is that neither of
thebehaviors
described thus far sounds very appealing as a feature, though I'm
certain there are some people who, with sufficient jiggering, could
make effective use of them.
...Robert
