Re: Race condition within _bt_findinsertloc()? (new page split code)

On 05/28/2014 02:15 AM, Peter Geoghegan wrote:
> On Tue, May 27, 2014 at 12:19 PM, Heikki Linnakangas
> <hlinnakangas(at)vmware(dot)com> wrote:
>>> Fair enough, but I don't think that affects correctness either way (I
>>> don't think that you meant to imply that this was a necessary
>>> precaution that you'd taken - right?).
>>
>> Right.
>
> So, the comments within _bt_search() suggest that the _bt_moveright()
> call will perform a _bt_finish_split() call opportunistically iff it's
> called from _bt_doinsert() (i.e. access == BT_WRITE). There is no
> reason to not do so in all circumstances though, assuming that it's
> desirable to do so as soon as possible (which I *don't* actually
> assume).

You can't write in a hot standby, so that's one reason to only do it
when inserting, not when querying. Even when you're not in a hot
standby, it seems like a nice property that a read-only query doesn't do
writes. I know we do hint bit updates and other kinds of write-action
when reading anyway, but still.

> If I'm not mistaken, it's also true that it would be strictly
> speaking correct to never do it there.

Hmm. No, it wouldn't. It is not allowed to have two incompletely-split
pages adjacent to each other. If you move right to the right-half of an
incomplete split, i.e. a page that does not have a downlink in its
parent, and then try to split the page again, _bt_insert_parent() would
fail to find the location to insert the new downlink to. It assumes that
there is a downlink to the page being split in the parent, and uses that
to find the location for the new downlink.

- Heikki