Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
В списке pgsql-performance по дате отправления:
| От | Andres Freund |
|---|---|
| Тема | Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? |
| Дата | |
| Msg-id | 201011170212.30033.andres@anarazel.de обсуждение исходный текст |
| Ответ на | Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-performance |
On Wednesday 17 November 2010 02:04:28 Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > On Wednesday 17 November 2010 01:51:28 Tom Lane wrote: > >> Well, there's a forced fsync after writing the last page of an xlog > >> file, but I don't believe that proves that more than 16MB of xlog > >> buffers is useless. Other processes could still be busy filling the > >> buffers. > > > > Maybe I am missing something, but I think the relevant > > AdvanceXLInsertBuffer() is currently called with WALInsertLock held? > > The fsync is associated with the write, which is not done with insert > lock held. We're not quite that dumb. Ah, I see. The XLogWrite in AdvanceXLInsertBuffer is only happening if the head of the buffer gets to the tail - which is more likely if the wal buffers are small... Andres
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера