Re: Why copy_relation_data only use wal whenWALarchivingis enabled
В списке pgsql-hackers по дате отправления:
| От | Jacky Leng |
|---|---|
| Тема | Re: Why copy_relation_data only use wal whenWALarchivingis enabled |
| Дата | |
| Msg-id | ff6cqj$26ie$1@news.hub.org обсуждение исходный текст |
| Ответ на | Why copy_relation_data only use wal when WAL archiving is enabled ("Jacky Leng" <lengjianquan@163.com>) |
| Ответы |
Re: Why copy_relation_data only use wal whenWALarchivingis
enabled
|
| Список | pgsql-hackers |
> Heikki Linnakangas <heikki@enterprisedb.com> writes: > I tend to agree that truncating the file, and extending the fsync > request mechanism to actually delete it after the next checkpoint, > is the most reasonable route to a fix. > How about just allowing to use wal even WAL archiving is disabled? It seems that recovery of "XLOG_HEAP_NEWPAGE" record will do the right thing for us, look at "heap_xlog_newpage": XLogReadBuffer with init=true will extend the block rightly and rebuild it rightly. Someone may say that it's not worth recording xlog for operations such as copy_relation_data, but these operations shouldn't happen frequently.
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера