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  ("alvherre@alvh.no-ip.org" <alvherre@alvh.no-ip.org>)
Список 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 по дате отправления:

Предыдущее
От: "Bossart, Nathan"
Дата:
Сообщение: Re: archive status ".ready" files may be created too early
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Proposal: More structured logging