Re: 64-bit XIDs in deleted nbtree pages
От | Peter Geoghegan |
---|---|
Тема | Re: 64-bit XIDs in deleted nbtree pages |
Дата | |
Msg-id | CAH2-Wzm+ywNByd_F_S5xMRrgTaZnYxf_fZ9JPWG3KK7aUkEvjw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: 64-bit XIDs in deleted nbtree pages (Peter Geoghegan <pg@bowt.ie>) |
Список | pgsql-hackers |
On Wed, Feb 10, 2021 at 7:10 PM Peter Geoghegan <pg@bowt.ie> wrote: > Attached is v3 of the index. I'll describe the changes I made in more > detail in my response to your points below. I forget to mention that v3 adds several assertions like this one: Assert(!_bt_page_recyclable(BufferGetPage(buf))); These appear at a few key points inside generic routines like _bt_getbuf(). The overall effect is that every nbtree buffer access (with the exception of buffer accesses by VACUUM) will make sure that the page that they're about to access is not recyclable (a page that an index scan lands on might be half-dead or deleted, but it had better not be recyclable). This can probably catch problems with recycling pages too early, such as the problem fixed by commit d3abbbeb back in 2012. Any similar bugs in this area that may appear in the future can be expected to be very subtle, for a few reasons. For one, a page can be recyclable but not yet entered into the FSM by VACUUM for a long time. (I could go on.) The assertions dramatically improve our chances of catching problems like that early. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: