| От | Pierre C |
|---|---|
| Тема | Re: Wrong docs on wal_buffers? |
| Дата | |
| Msg-id | op.voux3uooeorkce@apollo13 обсуждение исходный текст |
| Ответ на | Re: Wrong docs on wal_buffers? (Jeff Janes <jeff.janes@gmail.com>) |
| Список | pgsql-performance |
> And the risks are rather asymmetric. I don't know of any problem from > too large a buffer until it starts crowding out shared_buffers, while > under-sizing leads to the rather drastic performance consequences of > AdvanceXLInsertBuffer having to wait on the WALWriteLock while holding > the WALInsertLock, Suppose you have a large update which generates lots of WAL, some WAL segment switching will take place, and therefore some fsync()s. If wal_buffers is small enough that it fills up during the time it takes to fsync() the previous WAL segment, isn't there a risk that all WAL writes are stopped, waiting for the end of this fsync() ?
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера