Re: BUG #17741: vacuum process hangs after pg_surgery manipulations
От | Alvaro Herrera |
---|---|
Тема | Re: BUG #17741: vacuum process hangs after pg_surgery manipulations |
Дата | |
Msg-id | 20230129192421.pox3vbwqfscacdiu@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: BUG #17741: vacuum process hangs after pg_surgery manipulations (Masahiko Sawada <sawada.mshk@gmail.com>) |
Список | pgsql-bugs |
On 2023-Jan-18, Masahiko Sawada wrote: > While this is completely true and I agree, can we improve this > situation somewhat so that it ends up with an error instead of getting > hanged? Well, I don't know. I think in this case we would have to look at a patch that claimed to change the behavior, so that we can determine whether it's likely to break something else. > In this case, the tuple with a = 1, the root of the HOT chain, was > killed, and the tuple with a = 2 was heap-only tuple and HOT-updated. > In heap_page_prune(), we normally can prune the tuple with a = 2 as > part of pruning its chain, but since the root tuple was already killed > we could not prune this tuple. Then, we ended up retrying > heap_page_prune() since we saw as if the tuple became dead since > heap_page_prune() looked. My intuition for attacking this, is that we should definitely strive to change the behavior if the pattern of corruption is something that is seen to appear with some frequency. If it only happens because somebody was careless while running pg_surgery, then let's just leave it to her to complete the surgery. But if some unknown server bug causes it and we have a lot of people with vacuum hanging because of it, then I agree with might want to look for alternatives. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
В списке pgsql-bugs по дате отправления: