Re: SRA Win32 sync() code
| От | Jan Wieck |
|---|---|
| Тема | Re: SRA Win32 sync() code |
| Дата | |
| Msg-id | 3FB7D758.20608@Yahoo.com обсуждение исходный текст |
| Ответ на | Re: SRA Win32 sync() code (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: SRA Win32 sync() code
|
| Список | pgsql-patches |
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: >> Tom Lane wrote: >>> Seriously though, if we can move the bulk of the writing work into >>> background processes then I don't believe that there will be any >>> significant penalty for regular backends. > >> If the background writer starts using fsync(), we can have normal >> backends that do a write() set a shared memory boolean. We can then >> test that boolean and do sync() only if other backends had to do their >> own writes. > > That seems like the worst of both worlds --- you still are depending on > sync() for correctness. > > Also, as long as backends only *seldom* do writes, making them fsync a > write when they do make one will be less of an impact on overall system > performance than having a sync() ensue shortly afterwards. I think you > are focusing too narrowly on the idea that backends shouldn't ever wait > for writes, and failing to see the bigger picture. What we need to > optimize is overall system performance, not an arbitrary restriction > that certain processes never wait for certain things. Removing sync() entirely requires very accurate fsync()'ing in the background writer, the checkpointer and the backends. Basically none of them can mark a block "clean" if he fails to fsync() the relation later! This will be a mess to code. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
В списке pgsql-patches по дате отправления: