RE: [HACKERS] TODO item
От | Hiroshi Inoue |
---|---|
Тема | RE: [HACKERS] TODO item |
Дата | |
Msg-id | 000601bf735e$4bdda440$2801007e@tpf.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] TODO item (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
> -----Original Message----- > From: owner-pgsql-hackers@postgresql.org > [mailto:owner-pgsql-hackers@postgresql.org]On Behalf Of Tom Lane > > Tatsuo Ishii <t-ishii@sra.co.jp> writes: > > [ use a global sync instead of fsync ] > > > 1. Does sync really wait for the completion of data be written on to > > disk? > > Linux is *alone* among Unix platforms in waiting; every other > implementation of sync() returns as soon as the last dirty buffer > is scheduled to be written. > > > 2. Are we suffered any performance penalty from sync? > > A global sync at the completion of every xact would be disastrous for > the performance of anything else on the system. > > > However, in most cases the system is dedicated for only PostgreSQL, > > "Most cases"? Do you have any evidence for that? > Tatsuo is afraid of the delay of WAL OTOH,it's not so easy to solve this item in current spec. Probably he wants a quick and simple solution. His solution is only for limited OS but is very simple. Moreover it would make FlushBufferPool() more reliable( I don't understand why FlushBufferPool() is allowed to not call fsync() per page.). The implementation would be in time for 7.0. Is a temporary option unitl WAL bad ? Regards. Hiroshi Inoue Inoue@tpf.co.jp
В списке pgsql-hackers по дате отправления: