Re: Sync Rep: First Thoughts on Code
От | Simon Riggs |
---|---|
Тема | Re: Sync Rep: First Thoughts on Code |
Дата | |
Msg-id | 1229592909.4793.348.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: Sync Rep: First Thoughts on Code ("Fujii Masao" <masao.fujii@gmail.com>) |
Ответы |
Re: Sync Rep: First Thoughts on Code
|
Список | 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.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления: