Re: Faster inserts with mostly-monotonically increasing values

On Tue, Mar 6, 2018 at 1:45 AM, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> On Mon, Mar 5, 2018 at 7:10 PM, Claudio Freire <klaussfreire(at)gmail(dot)com> wrote:
>>> Introducing any case that allows us to land on a recycled page, and
>>> reason that it must at least not be the page we were looking for based
>>> on *any* criteria about the page itself seems very brittle. Yeah, it
>>> probably won't break in practice, but it's a bad design.
>>
>> How is this any different from btvacuumscan?
>>
>> I don't think it can be argued that somehow btvacuumscan has
>> permission to be brittle and the rest of the code doesn't.
>
> VACUUM doesn't have to worry about concurrent page recycling because
> it is already the only thing that performs page deletion. It's already
> the process that has the exclusive right to give index pages back to
> the FSM.

Not *concurrent* recycling, but it does have to handle *recycled*
pages correctly.

With the write lock, I don't think there's an issue with *concurrent*
recycling. According to the readme, leaf pages aren't deleted at all,
so only concurrent splitting is a concern.

The only issue is that we may land on a *recycled* page. Now, it
depends on what you mean by recycled here... if you mean "deleted",
!P_IGNORE will skip that page. If you mean it was deleted and freed
but not reused, again, !P_IGNORE will skip it (much as it happens for
vacuum). If you mean that someone reused it, then it will be a valid
page with valid headers, so we need not worry about it not being
consistent. It can be some other page than the one we expect it to be,
but the checks ought to be sufficient to quickly verify whether that's
the case.

Unless you see a way in which a write-locked page could say it is a
rightmost leaf when it is not?