Re: archive status ".ready" files may be created too early
От | Andres Freund |
---|---|
Тема | Re: archive status ".ready" files may be created too early |
Дата | |
Msg-id | 20210901002347.2u6tuqh53ulkl3wo@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: archive status ".ready" files may be created too early ("Bossart, Nathan" <bossartn@amazon.com>) |
Ответы |
Re: archive status ".ready" files may be created too early
|
Список | pgsql-hackers |
On 2021-08-31 23:31:15 +0000, Bossart, Nathan wrote: > 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. Maybe, but this is getting uglier and uglier. I think patch should be reverted. It's not in a state that's appropriate for the backbranches.
В списке pgsql-hackers по дате отправления: