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 по дате отправления: