On Tue, 2008-12-16 at 12:36 +0900, Fujii Masao wrote: > > 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. > > The above option should be configured on the primary? or standby? > The primary is suitable to vary it from transaction to transaction. On > the other hand, it should be configured on the standby in order to > choose it for every standby (in the future). > > I prefer the latter, and thought that it should be added into recovery.conf. > I mean, synchronous_replication identifies only whether commit waits for > replication (if the name is confusing, I would rename it). The above > options (#1-#6) are chosen in recovery.conf. What is your opion?
No, we've been through that loop already a few months back: Transaction-controlled robustness. It should be up to the client on the primary to decide how much waiting they would like to perform in order to provide a guarantee. A change of setting on the standby should not be allowed to alter the performance or durability on the primary. My perspective is that synchronous_replication specifies how long to wait. Current settings are "off" (don't wait) or "on" (meaning wait until point #3). So I think we should change this to a list of options to allow people to more carefully select how much waiting is required. This feature is then analogous to the way synchronous_commit works. It also provides a level of application control not seen in any other RDBMS in the industry, which makes it very suitable for large and important applications that need a fine mix of robustness and performance. -- 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
