Re: Logical replication: lost updates/deletes and invalid log messages caused by SnapshotDirty + concurrent updates - Mailing list pgsql-hackers

From Mihail Nikalayeu
Subject Re: Logical replication: lost updates/deletes and invalid log messages caused by SnapshotDirty + concurrent updates
Date
Msg-id CADzfLwXHGGZ51FYwTwu_V25eVMEQpndtU-ccPg-_6AuQgt+QEw@mail.gmail.com
Whole thread
In response to Re: Logical replication: lost updates/deletes and invalid log messages caused by SnapshotDirty + concurrent updates  (Mihail Nikalayeu <mihailnikalayeu@gmail.com>)
Responses Re: Logical replication: lost updates/deletes and invalid log messages caused by SnapshotDirty + concurrent updates
Re: Logical replication: lost updates/deletes and invalid log messages caused by SnapshotDirty + concurrent updates
List pgsql-hackers
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.

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pg_resetwal: refuse to run when backup_label exists
Next
From: Tom Lane
Date:
Subject: Re: [PG19] plpgsql: SELECT INTO sets FOUND wrongly after a function becomes a SRF