Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
От | Andres Freund |
---|---|
Тема | Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations |
Дата | |
Msg-id | 20220218221117.ijozsjwaxa6fy5u6@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
|
Список | pgsql-hackers |
Hi, On 2022-02-18 13:09:45 -0800, Peter Geoghegan wrote: > 0001 is tricky in the sense that there are a lot of fine details, and > if you get any one of them wrong the result might be a subtle bug. For > example, the heap_tuple_needs_freeze() code path is only used when we > cannot get a cleanup lock, which is rare -- and some of the branches > within the function are relatively rare themselves. The obvious > concern is: What if some detail of how we track the new relfrozenxid > value (and new relminmxid value) in this seldom-hit codepath is just > wrong, in whatever way we didn't think of? I think it'd be good to add a few isolationtest cases for the can't-get-cleanup-lock paths. I think it shouldn't be hard using cursors. The slightly harder part is verifying that VACUUM did something reasonable, but that still should be doable? Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: