RE: WAL does not recover gracefully from out-of-disk-sp ace

Поиск
Список
Период
Сортировка
От Mikheev, Vadim
Тема RE: WAL does not recover gracefully from out-of-disk-sp ace
Дата
Msg-id 8F4C99C66D04D4118F580090272A7A234D3300@sectorbase1.sectorbase.com
обсуждение исходный текст
Ответы Re: WAL does not recover gracefully from out-of-disk-sp ace  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> > I see that seek+write was changed to write-s in XLogFileInit
> > (that was induced by subj, right?), but what about problem
> > itself?
> 
> > BTW, were performance tests run after seek+write --> write-s
> > change?
> 
> That change was for safety, not for performance.  It might be a
> performance win on systems that support fdatasync properly (because it
> lets us use fdatasync), otherwise it's probably not a performance win.

Even with true fdatasync it's not obviously good for performance - it takes
too long time to write 16Mb files and fills OS buffer cache with trash-:(
Probably, we need in separate process like LGWR (log writer) in Oracle.
I also like the Andreas idea about re-using log files.

> But we need it regardless --- if you didn't want a fully-allocated WAL
> file, why'd you bother with the original seek-and-write-1-byte code?

I considered this mostly as hint for OS about how log file should be
allocated (to decrease fragmentation). Not sure how OSes use such hints
but seek+write costs nothing.

Vadim


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Performance monitor
Следующее
От: Tom Lane
Дата:
Сообщение: Checkpoint process signal handling seems wrong