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

Hi Mikhail, Hayato, Zsolt,

v21 looks good to me. On master 4848fd6752a the subscription suite
passes, 039 still fails without the execReplication.c hunks, and
Zsolt's original 041 (index and sequential search) fails on v20 but
passes on v21 and on unpatched master, so the failure came with v20
and is not pre-existing. Thanks, Zsolt, for catching that.

On Wed, Oct 28, 2026 at 7:10 AM Hayato Kuroda (Fujitsu)
<kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
> Can the performance decrease in the extreme case which
> the lots of XXX_missing happens?

Measured with -O2 builds, 10 interleaved pairs, conflicts logged as
by default. 1M one-row transactions that all miss apply in a median
4.28 s on master and 4.34 s with v21; paired ratio 1.006 (95% CI
0.988-1.024). With REPLICA IDENTITY FULL: 1.006 (1.000-1.011).
With a local writer committing ~128k/s on the subscriber: 1.009
(0.979-1.041). The only case outside the noise is 1M misses in a
single transaction: +1.9% (0.7-3.1%). Updates that find their row:
0.998 (0.994-1.002).

One behaviour change worth a line in the commit message if this is
back-patched: an ENABLE REPLICA or ALWAYS trigger on the subscriber
now runs at read committed whatever default_transaction_isolation says
(postgresql.conf, ALTER DATABASE or ALTER ROLE). At repeatable read
it now sees rows committed locally between two changes of the same
remote transaction; on master it did not.

Regards,
Manu