Re: [HACKERS] The dangers of "-F"
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] The dangers of "-F" |
Дата | |
Msg-id | 199906251259.IAA19774@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] The dangers of "-F" (Vadim Mikheev <vadim@krs.ru>) |
Список | pgsql-hackers |
> Bruce Momjian wrote: > > > > > > > > > For instance, if there are assumptions that all data blocks are > > > > written before this fact is recorded in a log file, then > > > > "write data blocks" "fsynch" "write log" "fsynch" doesn't break > > > > that assumption, > > > > > > > Are we really doing a sync after the pg_log write ? While the sync > > > after datablock write seems necessary to guarantee consistency, > > > the sync after log write is actually not necessary to guarantee consistency. > > > Would it be a first step, to special case the writing to pg_log, as > > > to not sync (extra switch to backend) ? This would avoid the syncs > > > for read only transactions, since they don't cause data block writes. > > > > You are right. We don't need a sync after the pg_log write. > > We need. I agreed with extra switch to backend. We need the switch only so was can "guarentee" that we can restore up until 30 seconds before crash. Without fsync of pg_log, we are waiting for the OS to do the sync, and that will add at most another 30 seconds of open time(OS's sync every 30 seconds, usually). One nice thing I think will be than an independent process will be doing the fsync, so no queries will have to wait for it to happen. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: