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) <[email protected]> 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
