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 <simon@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.comPostgreSQL Training, Services and Support