On Fri, 2008-12-12 at 12:53 +0900, Fujii Masao wrote: > > > > Quite possibly a terminology problem.. I my case I said "sync rep" > > meaning the mode such that the transaction doesn't commit successfully > > for my PG client until the xlog record has been "streamed" to the > > client... and I understand that at his presentation at PGcon, Fujii-san > > there could be possible variants on when the "streamed" is considered > > done based on network, slave ram, disk, application, etc. > > I'd like to define the meaning of "synch rep" again. "synch rep" means: > > (1) Transaction commit waits for WAL records to be replicated to the standby > before the command returns a "success" indication to the client.
> (2) The standby has (can read) all WAL files indispensable for recovery. I would change "can read" in (2) to "has access to". "Can read" implies we have read all files and checked CRCs of individual records. The crux of this is what we mean by "synchronous_replication = on". There are two possible meanings: 1. Commit will wait only if streaming is available and has waited for all necessary startup conditions. This provides "Highest Availability" 2. Commit will wait *until* full sync rep is available. So we don't allow it until standby fails and also don't allow it if standby goes down. This provides "Highest Transaction Durability", though is fairly fragile. Other systems recommend use of multiple standby nodes if this option is selected. Perhaps we should add this as a third option to synchronous_replication, so we have either off, on, only So far I realise I've been talking exclusively about (1). In that mode synchronous_replication = on would wait for streaming to complete even if last WAL file not fully transferred. For (2) we need a full interlock. Given that we don't currently support multiple streamed standby servers, it seems not much point in implementing the interlock (2) would require. Should we leave that part for 8.5, or do it now? -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
