Re: Sync Rep: First Thoughts on Code

Hi,

On Thu, Dec 18, 2008 at 11:19 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>
> 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.

If my understanding is correct, XLOG flush is forced up to buffer's LSN
when flushing buffer even if asynchronous commit case. Am I missing
something?

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center