* Markus Wanner <mar...@bluegap.ch> [081213 16:33]: > Hi, > > Hannu Krosing wrote: > > You can have a variantof sync rep + hot standby where the master does > > not return committed before the slave has both synced the data and > > replied the transaction so that it is visible on slave but in that case > > you may have a usecase, where it is actually visible on slave _before_ > > it is visible on master. > > As long as it's not visible *before* the client requests a COMMIT, that > certainly doesn't matter (because the application cannot check that).
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.... 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. 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. But in the current patch, it focusses on the streaming (sending), and and a receiver "recovery" mode that can accept/apply them, again, without worrying about acutally running queries (yet) ... a. -- Aidan Van Dyk Create like a god, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
signature.asc
Description: Digital signature
