Re: nbtree VACUUM's REDO routine doesn't clear page's VACUUM cycle ID
| От | Peter Geoghegan |
|---|---|
| Тема | Re: nbtree VACUUM's REDO routine doesn't clear page's VACUUM cycle ID |
| Дата | |
| Msg-id | CAH2-WznCv0XkTYnAhemSaN=P=PVCk1oWoEBOm-9WQcmB4KoSDw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: nbtree VACUUM's REDO routine doesn't clear page's VACUUM cycle ID (Andrey Borodin <x4mmm@yandex-team.ru>) |
| Ответы |
Re: nbtree VACUUM's REDO routine doesn't clear page's VACUUM cycle ID
|
| Список | pgsql-hackers |
On Tue, Nov 18, 2025 at 1:32 AM Andrey Borodin <x4mmm@yandex-team.ru> wrote: > I'm thinking more about it. We always reset btpo_cycleid even in redo of a split. > This "btpo_cycleid = 0;" reset can break two scenarios that are not currently supported by us, but might be supported infuture. I don't follow. > This reset is based on the idea that crash recovery will interrupt vacuum. It is not true in these cases. It's also based on the idea that only one VACUUM operation can be running at a time. > 1. We are dealing with compute-storage separation system. We do not have filesystem and when we need to read a page weget it from some storage service, that rebuild pages from WAL. (e.g. Aurora and Neon) If we split a page during vacuum,evict it and read it from service - we will miss needed backtrack to the left page... Are you arguing that the xl_btree_split record should include the cycleid? I see that systems that are built on this architecture do something along these lines: https://github.com/neondatabase/postgres/commit/a9b92820c5d14dbff8f59ab65ffdaae92ab9c3c8 However, that seems well out of scope for core Postgres. At least for the foreseeable future. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: