Re: Async Commit, v21 (now: v22)
От | Simon Riggs |
---|---|
Тема | Re: Async Commit, v21 (now: v22) |
Дата | |
Msg-id | 1185270243.4261.6.camel@ebony.site обсуждение исходный текст |
Ответ на | Re: Async Commit, v21 (now: v22) (Florian Weimer <fweimer@bfk.de>) |
Ответы |
Re: Async Commit, v21 (now: v22)
|
Список | pgsql-patches |
On Tue, 2007-07-24 at 10:51 +0200, Florian Weimer wrote: > + <para> > + Asynchronous commit provides different behaviour to setting > + <varname>fsync</varname> = off, which is a server-wide > + setting that will alter the behaviour of all transactions, > + overriding the setting of <varname>synchronous_commit</varname>, > + as well as risking much wider data loss. With <varname>fsync</varname> > + = off the WAL written but not fsynced, so data is lost only in case > + of a system crash. Both WAL and datafiles written within the last > + few seconds would be at risk, affecting all types of database > + transactions. The precise number depends upon whether your operating > + system is configured for automatic filesystem writeback and what the > + delay is set too; Linux currently defaults to 30 seconds. With > + asynchronous commit the WAL is not written to disk at all at commit > + time, so data is lost if there is a database server crash, whether or > + not the system crashes at the same time. > + </para> > > I think fsync=off also endagers metadata, while synchronous_commit=off > should be perfectly safe as far as the metadata is concerned. > Wouldn't this be worth mentioning as well? Well, I think "wider data loss" covers it for me, but I don't have a problem with people wanting to detail the various problems that can occur. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
В списке pgsql-patches по дате отправления: