Re: Should the nbtree page split REDO routine's locking work more like the locking on the primary?

Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> I'm starting to think that we should bite the bullet and not release
> all same-level locks within btree_xlog_split() until the very end,
> along with the existing right sibling page whose left link we need to
> update.

+1 for making this more like what happens in original execution ("on the
primary", to use your wording). Perhaps what you suggest here is still
not enough like the original execution, but it sounds closer.

> My sense is that the current approach to locking taken within
> btree_xlog_split() is kind of an accident, not something that was
> pursued as a special optimization for the REDO routine at some point.
> Commit 3bbf668d certainly creates that impression. But I might have
> missed something.

As the commit message for 3bbf668d explains, the initial situation for
all the replay code was that it executed by itself in crash recovery and
didn't need to bother with locks at all. I think that it did take some
locks even then, but that was because of code sharing with the primary
execution path rather than being something we wanted. Once we invented
Hot Standby that situation had to be improved. It seems to me that the
goal now needs to be to replicate the primary-execution buffer locking
behavior in any case where we can't prove that something simpler is safe.
3bbf668d did not claim to achieve that everywhere, and it didn't; it
doesn't surprise me that there's work left to be done.

regards, tom lane