From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
Cc: | PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, "K(dot) R(dot)" <iijima(dot)yun(at)koumakan(dot)jp> |
Subject: | Re: BUG #17245: Index corruption involving deduplicated entries |
Date: | 2021-10-25 23:18:52 |
Message-ID: | CAH2-WzkrSY_kjyd1_M5xJK1uM0govJXMxPn8JUSvwcUOiHuWVw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Sun, Oct 24, 2021 at 6:33 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> Anything is possible, but this doesn't look like logical index
> corruption. If we assume that it was something like a faulty
> deduplication pass, then we have to explain how the spurious TID ended
> up in that particular leaf page to begin with. We also have to explain
> why it is a valid TID though totally distinct TID, which is unlikely
> to occur by chance.
I discussed the robustness of some of the posting list split code
privately with Heikki earlier today. Heikki suggested that I more
consistently invalidate the insert state that is used across
nbtinsert.c. Although I don't have any reason to believe that that
makes a difference, I still agree with his conclusions.
Attached patch does this. It also makes the special posting split
related call to _bt_binsrch_insert() at the end of _bt_findinsertloc()
more robust. There is a similar defensive elog() within
_bt_swap_posting(), but that only kicks in when the posting offset is
totally out of bounds for the tuple. _bt_binsrch_insert() could still
give answers for some other reason, at least in theory, and so it
seems like a good idea to be extra careful, and throw an error at the
earliest opportunity.
--
Peter Geoghegan
Attachment | Content-Type | Size |
---|---|---|
v1-0001-Harden-nbtinsert.c-posting-split-code.patch | application/octet-stream | 2.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2021-10-25 23:20:59 | Re: BUG #17229: Segmentation Fault after upgrading to version 13 |
Previous Message | Thomas Munro | 2021-10-25 22:05:07 | Re: BUG #17245: Index corruption involving deduplicated entries |