Hi Mihail, > That behavior on master is racy, though. It only waits if the insert > has already made it into the index by the time the scan reaches it. > If the INSERT happens a little later, master reports update_missing as > well. In either case there is no committed row at the time the > replicated change is applied, which is different from the bug this > patch fixes, where the row exists throughout.
Agreed. The dirty scan only waits when it actually finds the in-progress tuple, so on master the outcome already depends on whether the INSERT reached the index before the scan reached it; the patch just makes the "no committed row" outcome deterministic instead of racy. That is a different situation from the one the patch fixes, where a committed row is there throughout, and the updated commit message draws that line clearly. > Manu also suggested doing another dirty scan when nothing is found, to > preserve the wait in more cases. That works, but it only makes the > race window smaller and reintroduces a dirty scan, so I left it out of > a fix intended to be back-patchable. Makes sense -- it only narrows the window and brings a dirty scan back, so leaving it out of a back-patchable fix is the right call. The v20 code here is the same one I tested earlier, and the reproduction still shows the fix holding. Looks good to me.
