From: | Nisha Moond <nisha(dot)moond412(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, shveta malik <shveta(dot)malik(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, vignesh C <vignesh21(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Subject: | Re: Conflict detection for update_deleted in logical replication |
Date: | 2025-09-01 04:02:21 |
Message-ID: | CABdArM7ZmOpCSow0n08xFB36rEwraMiuzCnwx2seyq2nqNbiVg@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Aug 28, 2025 at 6:00 PM Nisha Moond <nisha(dot)moond412(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alexandra Wang | 2025-09-01 04:11:08 | Re: SQL:2023 JSON simplified accessor support |
Previous Message | shveta malik | 2025-09-01 03:45:40 | Re: Issue with logical replication slot during switchover |