Re: Logical replication: lost updates/deletes and invalid log messages caused by SnapshotDirty + concurrent updates

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.