Re: Better HINT message for "unexpected data beyond EOF"
От | Robert Haas |
---|---|
Тема | Re: Better HINT message for "unexpected data beyond EOF" |
Дата | |
Msg-id | CA+TgmoYupgugOXiTQ5hZnDVXeB-KEZM3CsheTKv6qa6zsA4GEg@mail.gmail.com обсуждение исходный текст |
Ответ на | Better HINT message for "unexpected data beyond EOF" (Jakub Wartak <jakub.wartak@enterprisedb.com>) |
Ответы |
Re: Better HINT message for "unexpected data beyond EOF"
|
Список | pgsql-hackers |
On Wed, Mar 26, 2025 at 4:59 AM Jakub Wartak <jakub.wartak@enterprisedb.com> wrote: > ERROR: unexpected data beyond EOF in block 1472 of relation base/5/16387 > HINT: This has been seen to occur with buggy kernels; consider > updating your system. > > to something more generic and less confusing. It is coming from > ffae5cc5a602 (2006), and we are probably not running those "buggy" > kernels anywhere. I've seen this error multiple times, but it is > usually due to some external influence overwriting/replacing the files > in PGDATA and some (potentially new) backends open()ing those "new" > files and finding unexpected file layout. In the real world this means > usually: > a. files being potentially accidentally replaced/overwritten, please > see attached file for reproducer > b. some obscure bugs (e.g. in EPAS - PG fork - we have on-demand > automatic partition creation and we had bug/race conditions where > multiple backends end up writing to the same relfilenode oid file) > > so how about: > -HINT: This has been seen to occur with buggy kernels; consider > updating your system. > +HINT: This has been observed with files being overwritten, buggy > kernels and potentially other external file system influence. I agree that we should emphasize the possibility of files being overwritten. I'm not sure we should even mention buggy kernels -- is there any evidence that's still a thing on still-running hardware? I don't really like "other external file system influence" because that sounds like vague weasel-wording. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: