Re: Trying to minimize the impact of checkpoints
От | Martijn van Oosterhout |
---|---|
Тема | Re: Trying to minimize the impact of checkpoints |
Дата | |
Msg-id | 20040613002630.GA13910@svana.org обсуждение исходный текст |
Ответ на | Re: Trying to minimize the impact of checkpoints (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Trying to minimize the impact of checkpoints
|
Список | pgsql-general |
On Sat, Jun 12, 2004 at 04:00:46PM -0400, Tom Lane wrote: > There was talk earlier of providing an option to issue sync() before > starting the loop that issues fsync() against each file we've written > since the last checkpoint. The idea was that the sync() would cue the > kernel to schedule I/O for all currently dirty buffers in the most > efficient order, and then the fsync()s would merely ensure that Postgres > waits until the I/O it needs is done. This should be optional since it <snip> Not a good idea on some systems. From the linux sync(2) manpage: BUGS According to the standard specification (e.g., SVID), sync() schedules the writes, but may return before the actual writing is done. However, since version 1.3.20 Linux does actually wait. (This still does not guaran- tee data integrity: modern disks have large caches.) So your fsyncs become no-ops instead. And I don't think we need a discussion on whether this behaviour is correct or not, this is the way it is, I don't know why. I wonder if any other systems works this way... -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
Вложения
В списке pgsql-general по дате отправления: