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
|
Список | 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 по дате отправления: