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