Re: archive status ".ready" files may be created too early
Вложения
В списке pgsql-hackers по дате отправления:
| От | Bossart, Nathan |
|---|---|
| Тема | Re: archive status ".ready" files may be created too early |
| Дата | |
| Msg-id | 83EB9B6A-A6B6-40AB-8B70-0F536CB54BDA@amazon.com обсуждение исходный текст |
| Ответ на | Re: archive status ".ready" files may be created too early (Andres Freund <andres@anarazel.de>) |
| Ответы |
Re: archive status ".ready" files may be created too early
|
| Список | pgsql-hackers |
On 8/31/21, 1:30 PM, "Andres Freund" <andres@anarazel.de> wrote: > On 2021-08-31 18:09:36 +0000, Bossart, Nathan wrote: >> What appears to happen in this case is that bgwriter eventually creates a >> xl_running_xacts record and nudges walwriter to flush it to disk, at which >> point the .ready file(s) will be created. That's admittedly a bit fragile. > > That's not guaranteed to happen. If e.g. the partial record is a checkpoint or > a xl_running_xacts, we'll not trigger further WAL writes in the background, > unless autovacuum ends up doing something. Right. Per the attached patch, a simple way to handle that could be to teach XLogBackgroundFlush() to flush to the "earliest" segment boundary if it doesn't find anything else to do. I think you could still miss creating a .ready file for the previous segment in single- user mode, though. Nathan
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера