RE: Logical replication timeout problem
Wei Wang (Fujitsu) <wangw.fnst@fujitsu.com>
From: "wangw.fnst@fujitsu.com" <wangw.fnst@fujitsu.com>
To: Masahiko Sawada <sawada.mshk@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>
Cc: "kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>, Peter Smith <smithpb2250@gmail.com>, Fabrice Chapuis <fabrice636861@gmail.com>, Simon
Riggs <simon.riggs@enterprisedb.com>, Petr Jelinek <petr.jelinek@enterprisedb.com>, "tanghy.fnst@fujitsu.com" <tanghy.fnst@fujitsu.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Ajin Cherian <itsajin@gmail.com>
Date: 2022-03-18T05:13:02Z
Lists: pgsql-hackers
Attachments
- v3-0001-Fix-the-timeout-of-subscriber-in-long-transaction.patch (application/octet-stream) patch v3-0001
On Thu, Mar 17, 2022 at 7:52 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > Thanks for your comments. > On Thu, Mar 17, 2022 at 7:14 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > On Thu, Mar 17, 2022 at 12:27 PM Amit Kapila <amit.kapila16@gmail.com> > wrote: > > > > > > On Wed, Mar 16, 2022 at 7:38 PM Masahiko Sawada > <sawada.mshk@gmail.com> wrote: > > > > > > > > After more thought, can we check only wal_sender_timeout without > > > > skip-count? That is, in WalSndUpdateProgress(), if we have > > > > received any reply from the subscriber in last (wal_sender_timeout > > > > / 2), we don't need to do anything in terms of keep-alive. If not, > > > > we do > > > > ProcessRepliesIfAny() (and probably WalSndCheckTimeOut()?) then > > > > WalSndKeepalivesIfNecessary(). That way, we can send keep-alive > > > > messages every (wal_sender_timeout / 2). And since we don't call > > > > them for every change, we would not need to worry about the overhead > much. > > > > > > > > > > But won't that lead to a call to GetCurrentTimestamp() for each > > > change we skip? IIUC from previous replies that lead to a slight > > > slowdown in previous tests of Wang-San. > > > > > If the above is true then I think we can use a lower skip_count say 10 > > along with a timeout mechanism to send keepalive message. This will > > help us to alleviate the overhead Wang-San has shown. > > Using both sounds reasonable to me. I'd like to see how much the overhead is > alleviated by using skip_count 10 (or 100). > > > BTW, I think there could be one other advantage of using > > ProcessRepliesIfAny() (as you are suggesting) is that it can help to > > release sync waiters if there are any. I feel that would be the case > > for the skip_empty_transactions patch [1] which uses > > WalSndUpdateProgress to send keepalive messages after skipping empty > > transactions. > > +1 I modified the patch according to your and Amit-San's suggestions. In addition, after testing, I found that when the threshold is 10, it brings slight overhead. So I try to change it to 100, after testing, the results look good to me. 10 : 1.22%--UpdateProgress 100 : 0.16%--UpdateProgress Please refer to attachment. Attach the new patch. 1. Refactor the way to send keepalive messages. [suggestion by Sawada-San, Amit-San.] 2. Modify the value of flag is_send initialization to make it look more reasonable. [suggestion by Kuroda-San.] 3. Improve new function names. (From SendKeepaliveIfNecessary to UpdateProgress.) Regards, Wang wei
Commits
-
Fix the logical replication timeout during large DDLs.
- 8c58624df462 16.0 landed
-
Fix the logical replication timeout during large transactions.
- f95d53eded55 15.0 landed
- d6da71fa8f28 14.4 landed
- 55558df23741 13.8 landed
- f832b5007c1c 12.12 landed
- 87c1dd246af8 11.17 landed
- a4015ec0375d 10.22 landed
-
Rethink the delay-checkpoint-end mechanism in the back-branches.
- 10520f434687 14.3 cited
-
Revert "Logical decoding of sequences"
- 2c7ea57e56ca 15.0 cited
-
Skip empty transactions for logical replication.
- d5a9d86d8ffc 15.0 cited
-
Allow specifying column lists for logical replication
- 923def9a533a 15.0 cited
-
Add decoding of sequences to built-in replication
- 75b1521dae1f 15.0 cited
-
Fix ABI break introduced by commit 4daa140a2f.
- 56e366f6757d 13.4 cited
-
Lag tracking for logical replication
- 024711bb5446 10.0 cited