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

Hello, everyone!

Manu reviewed the fix in the original thread [1] and pointed out a
behavior change. I'm replying here since this thread is about the
logical replication side.

The case is this: a local transaction inserts a row and remains open,
while an UPDATE for the same key arrives from the publisher. On
master, the dirty scan may see the uncommitted row, wait for the
inserter, and then apply the UPDATE after it commits. With the patch,
the row isn't visible, so we report update_missing immediately.

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. I've updated the commit
message to make that distinction clear.

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.

[1]: https://postgr.es/m/179010806896.909920.249094834696255448@gmail.com
Best regards,
Mikhail.