Hello, Peter. >> * Add code to _bt_killitems() that detects if it has generated an FPI, >> just to set some LP_DEAD bits. >> * Instead of avoiding the FPI when this happens, proactively call >> _bt_simpledel_pass() just before _bt_killitems() returns. Accept the >> immediate cost of setting an LP_DEAD bit, just like today, but avoid >> repeated FPIs.
> Yes, I am almost sure proactively calling of_bt_simpledel_pass() will > positively impact the system on many workloads. But also I am almost > sure it will not change the behavior of the incident I mention - > because it is not related to multiple checkpoints. I just realized what it seems to be dangerous approache because of locking mechanism. Currently _bt_killitems requires only read lock but _bt_simpledel_pass required write lock (it ends with _bt_delitems_delete). It will required to increase locking mode in order to call _bt_simpledel_pass. Such a change may negatively affect many workloads because of write lock during scanning - and it is really hard to to prove absence of regression (have no idea how). Thanks, Michail.
