From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Sync Rep: First Thoughts on Code |
Date: | 2008-12-18 09:35:09 |
Message-ID: | 1229592909.4793.348.camel@ebony.2ndQuadrant |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2008-12-18 at 12:08 +0900, Fujii Masao wrote:
> >> 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?
Yes, please check the call points for ForceSyncCommit.
Do I think every xlog flush should be synchronous, no, I don't. That's
why we have a user settable parameter for it.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-12-18 09:40:27 | Re: Preventing index scans for non-recoverable index AMs |
Previous Message | Simon Riggs | 2008-12-18 09:32:35 | Re: rmgr hooks (v2) |