From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: xid wraparound danger due to INDEX_CLEANUP false |
Date: | 2020-04-29 21:25:15 |
Message-ID: | CAH2-WznFoJZEZHYPJKOn9xJCLQUERJEEhc2TvtFsOUmvDBdDxg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Apr 29, 2020 at 2:04 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> As a bonus, we now have an easy correctness cross-check: if some
> random piece of nbtree code lands on a page (having followed a
> downlink or sibling link) that is marked recycled, then clearly
> something is very wrong -- throw a "can't happen" error.
If this doesn't sound that appealing to any of you, then bear this in
mind: nbtree has a terrifying tendency to *not* produce wrong answers
to queries when we land on a concurrently-recycled page.
_bt_moveright() is willing to move right as many times as it takes to
arrive at the correct page, even though in typical cases having to
move right once is rare -- twice is exceptional. I suppose that there
is roughly a 50% chance that we'll end up landing at a point in the
key space that is to the left of the point where we're supposed to
arrive at. It might take many, many page accesses before
_bt_moveright() finds the correct page, but that often won't be very
noticeable. Or if it is noticed, corruption won't be suspected --
we're still getting a correct answer.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Jonah H. Harris | 2020-04-29 21:54:04 | Re: Proposing WITH ITERATIVE |
Previous Message | Peter Geoghegan | 2020-04-29 21:04:40 | Re: xid wraparound danger due to INDEX_CLEANUP false |