Re: BUG #17257: (auto)vacuum hangs within lazy_scan_prune()
От | Robert Haas |
---|---|
Тема | Re: BUG #17257: (auto)vacuum hangs within lazy_scan_prune() |
Дата | |
Msg-id | CA+TgmoZ5KMCMmomLevpEODrj9RhrdZ3BzWh8GHNO-Hg3JgnirQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17257: (auto)vacuum hangs within lazy_scan_prune() (Alexander Lakhin <exclusion@gmail.com>) |
Список | pgsql-bugs |
On Tue, Apr 9, 2024 at 4:00 PM Alexander Lakhin <exclusion@gmail.com> wrote: > I was talking about both — dad1539ae eliminated the bug (judging from the > repro) on REL_14_STABLE, and I suppose that 18b87b201 did the same for > REL_15_STABLE/REL_16_STABLE... > (On 18b87b201~1 I've got (twice): > TRAP: FailedAssertion("HeapTupleHeaderIsHeapOnly(htup)", File: "pruneheap.c", Line: 964, PID: 1854895) I'm inclined to believe that there's a residual bug here, or at least that there was one before 6dbb490261a6170a3fc3e326c6983ad63e795047 and related commits. But if we can't reproduce the issue, I don't know how much we can realistically do here. This logic is so complicated and so tricky that I don't trust myself to say "yes, this is definitely wrong, and after change XYZ it's definitely right." The bug is as likely to be in my analysis as it is to be in the code itself. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-bugs по дате отправления: