Hi,
Aidan Van Dyk wrote:
> Well, I think the PG MVCC (which wal-streaming just ships across
> somewhere else) will save that. So with hot-standby you could have
> another client could see the result *after* the COMMIT has been
> requested, but *before* the COMMIT returns... But we have this
> situation in a single current PG instance anyways, so it's nothing
> new....
AFAIU the proposed algorithm only waits until WAL is written on the
slave before acknowledging COMMIT. Application of the changes may be
deferred, so it's not necessarily immediately visible on the slave.
> But with hot-standby, I could also see that it could be done such that
> the wal-stream is fsynced to disk (i.e. xlog) and acknowledged, but
> because of a current running query, application of it is delayed... But
> this is hot-standby's problem of describing itself, not sync-rep.
I'm thinking of the overall system and don't care much if it's
hot-standby's or sync-rep's problem. But it's certainly the master which
needs to await certain acknowledgments of the slaves. That has so far
been discussed within this sync-rep thread.
> IMHO, sync-rep is about getting the change "durrably to a slave" before
> acknoledging the COMMIT. That slave could be any number of things:
> - A "WAL archive" type system having the ability to be used for
> recover
> - A PG with special "recovery mode" that reads the stream and applies it
> - A full hot-standby recovery
>
> I could see any and all of those (and probably other) being usefull and
> used.
I certainly agree to that.
Regards
Markus Wanner