On Thu, Aug 28, 2025 at 6:00 PM Nisha Moond <nisha.moond...@gmail.com> wrote: > > Test-04. pgbench on both side, and max_conflict_retention_duration was tuned > ======================================================================== > Setup: > ------- > Pub --> Sub > - setup is same as Test-03(above) > - Additionally, subscription option max_conflict_retention_duration=60s > > Workload: > ------------- > - Run default pgbench(read-write) on both Pub and Sub nodes for their > respective pgbench tables > - Started with 15 clients on both sides. > - When conflict_slot.xmin becomes NULL on Sub, pgbench was paused to > let the subscription catch up. Then reduced publisher clients by half > and resumed pgbench. Here, slot.xmin becomes NULL to indicate conflict > retention is stopped under high publisher load but stays non-NULL when > Sub is able to catchup with Pub's load. > - Total duration of pgbench run is 10 minutes (600s). > > Observations: > ------------------ > - Without the parallel apply patch, publisher clients reduced from > 15->7->3,and finally the retention was not stopped at 3 clients and > slot.xmin remained non-NULL. > - With the parallel apply patch, using 2 workers the subscription > handled up to 7 publisher clients without stopping the conflict > retention. > - With 4+ workers, retention continued for the full 10 minutes and > Sub TPS showed no regression. >
I repeated the test with 4 parallel workers over a 12-hour pgbench run. Retention continued for the full duration without stopping, and no regression was observed on either publisher or subscriber. Here is the pgbench result for the run on the publisher node - number of clients: 15 number of threads: 15 maximum number of tries: 1 duration: 43200 s number of transactions actually processed: 725093972 number of failed transactions: 0 (0.000%) latency average = 0.893 ms latency stddev = 1.176 ms initial connection time = 8.879 ms tps = 16784.585718 (without initial connection time) ~~~ Subscriber's TPS = 16668.322700 -- Thanks, Nisha
