On Tue, May 27, 2014 at 12:19 PM, Heikki Linnakangas <hlinnakan...@vmware.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). If I'm not mistaken, it's also true that it would be strictly speaking correct to never do it there. Do you think it would be a fair stress-test if I was to hack Postgres so that this call never happens (within _bt_moveright())? I'd also have an incomplete page split occur at random with a probability of, say, 1% per split. The mechanism would be much the same as your original test-case for the split patch - I'd throw an error at the wrong place, although only 1% of the time, and over many hours. The concern with the _bt_moveright() call of _bt_finish_split() is that it might conceal a problem without reliably fixing it, potentially making isolating that problem much harder. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
