On Fri, Mar 27, 2020 at 8:58 AM Michail Nikolaev <michail.nikol...@gmail.com> wrote: > I have spent some time trying to find any possible race condition > between btree_xlog_split and _bt_walk_left… But I can’t find any. > Also, I have tried to cause any issue by putting pg_sleep put into > btree_xlog_split (between releasing and taking of locks) but without > any luck.
I pushed a commit that tries to clear up some of the details around how locking works during page splits. See commit 9945ad6e. > I agree it is better to keep the same locking logic for primary and > standby in general. But it is a possible scope of another patch. It seems useful, but only up to a point. We don't need to hold locks across related atomic operations (i.e. across each phase of a page split or page deletion). In particular, the lock coupling across page levels that we perform on the primary when ascending the tree following a page split doesn't need to occur on standbys. I added something about this to the nbtree README in commit 9f83468b353. I'm not surprised that you didn't find any problems in btree_xlog_split(). It is already conservative about locking the sibling/child pages. It could hardly be more conservative (though see the code and comments at the end of btree_xlog_split(), which mention locking and backwards scans directly). -- Peter Geoghegan
