Fujii-san,
Just repeating this in case you lost this comment:
On Mon, 2008-12-15 at 09:40 +0000, Simon Riggs wrote:
> Fujii-san, please can we incorporate those two options, rather than just
> one choice "synchronous_replication = on". They look like two commonly
> requested options.
I see the comment in line 230+ of walreceiver.c, so understand that you
have implemented option #3 from the following list.
So from my previous list
1. We sent the message to standby (A)
2. We received the message on standby
3. We wrote the WAL to the WAL file (B)
4. We fsync'd the WAL file (C)
5. We CRC checked the WAL commit record
6. We applied the WAL commit record
Please could you also add an option #4, i.e. add the *option* to fsync
the WAL to disk at commit time also. That requires us to add a third
option to synchronous_replication parameter.
That then means we will have robustness options that map directly to
DRBD algorithms A, B and C (shown in brackets in the above list). I
believe these map also to Data Guard options Maximum Performance and
Maximum Availability.
AFAICS if we implement the additional items I've requested over the last
few days, then the architecture is now at a good point for 8.4 and we
can begin to look at low level implementation details. Or put another
way, I'm not expecting to come up with more architecture changes.
> #6 is an additional synchronization step in Hot Standby. I would say
> that people won't want that when they see how it performs (they probably
> won't want #4 either for that same reason, but that is for robustness).
We can jointly add option #6 once we have both sync rep and hot standby
committed, or at a late stage of hot standby development. There's not
much point looking at it before then.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
