Re: possible bug in handling of contrecords in dd38ff28ad (Fix recovery_prefetch with low maintenance_io_concurrency)

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: possible bug in handling of contrecords in dd38ff28ad (Fix recovery_prefetch with low maintenance_io_concurrency)
Дата
Msg-id CA+hUKGKP-Nqxuem+gqRmPM-1O-nhT2fLy5WoL=-=LoPynPk0Xw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: possible bug in handling of contrecords in dd38ff28ad (Fix recovery_prefetch with low maintenance_io_concurrency)  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Список pgsql-hackers
On Mon, Jul 3, 2023 at 6:12 AM Tomas Vondra
<tomas.vondra@enterprisedb.com> wrote:
> On 7/2/23 04:09, Thomas Munro wrote:
> > When I added that new error I was thinking about that third case.  We
> > generally expect to detect the end of WAL replay after a crash with an
> > error ("invalid record length ...: wanted 24, got 0" + several other
> > possibilities), but in this rare case it would be silent.  The effect
> > on the first two cases is cosmetic, but certainly annoying.  Perhaps I
> > should go ahead and back-patch the attached change, and then we can
> > discuss whether/how we should do a better job of distinguishing "user
> > requested artificial end of decoding" from "unexpectedly ran out of
> > data" for v17?
> >
>
> Yeah, I think that'd be sensible. IMHO we have a habit of scaring users
> with stuff that might be dangerous/bad, but 99% of the time it's
> actually fine and perhaps even expected. It's almost as if we're
> conditioning people to ignore errors.

Done.

There is CF #2490 "Make message at end-of-recovery less scary".
Perhaps we should think about how to classify this type of failure in
the context of that proposal.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Replacing abort() with __builtin_trap()?
Следующее
От: Yurii Rashkovskii
Дата:
Сообщение: Re: [PATCH] Extend the length of BackgroundWorker.bgw_library_name