On Thu, 2008-12-18 at 11:03 +0900, Fujii Masao wrote: > Hi, > > Thanks for the helpful comments! > > On Wed, Dec 17, 2008 at 8:50 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > > > > On Wed, 2008-12-17 at 12:07 +0900, Fujii Masao wrote: > > > >> OK. I will extend synchronous_replication, make walsender send XLOG > >> with synchronization mode flag and make walreceiver perform according > >> to the flag. > > > > Sounds good. > > > >> > 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. > >> > >> In the latest patch, "off" keeps us waiting for replication in some > >> cases, e.g. forceSyncCommit = true. This is analogous to the way > >> synchronous_commit works. When "off" keeps us waiting for > >> replication, which option (#1-#6) should we choose? Should it be > >> user-configurable (though the parameter values are doubled)? > >> hardcode #3? "off" always should not keep us waiting for > >> replication? > > > > I would hard code #4, i.e. make it fsync, so that DDL changes are > > regarded as "high value transactions". > > > > A parameter sounds like overkill. We'd need to explain what > > forceSyncCommit does to users then, which is easier to avoid. > > Agreed, I also think that hard code is better. But I'm nervous that "off" > keeps us waiting for replication in cases other than DDL, e.g. flush > buffer, truncate clog, checkpoint.. etc. synchronous_replication = off > is quite similar to synchronous_commit = off. If we would hard code #4, > the performance might degrade although it's asynchronous replication. > So, I'd like to hard code #3. What is your opinion?
We don't do that when we flush buffer, truncate clog or checkpoint, not sure why you mention those. We ForceSyncCommit when we * VACUUM FULL * CREATE/DROP DATABASE or USER * Create/Drop Tablespace I don't see a problem in forcing an fsync for those. I will sleep safer knowing those guys are on disk even in async mode. -- 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
