RE: Logical replication timeout problem

From: "wangw(dot)fnst(at)fujitsu(dot)com" <wangw(dot)fnst(at)fujitsu(dot)com>
To: Ajin Cherian <itsajin(at)gmail(dot)com>
Cc: "kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, Fabrice Chapuis <fabrice636861(at)gmail(dot)com>, Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>, Petr Jelinek <petr(dot)jelinek(at)enterprisedb(dot)com>, "tanghy(dot)fnst(at)fujitsu(dot)com" <tanghy(dot)fnst(at)fujitsu(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: RE: Logical replication timeout problem
Date: 2022-03-09 02:25:15
Message-ID: OS3PR01MB6275F8806E804C30CEF71ABF9E0A9@OS3PR01MB6275.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tues, Mar 8, 2022 at 11:54 PM Ajin Cherian <itsajin(at)gmail(dot)com> wrote:
> Some comments.
Thanks for your comments.

> 1. The comment on top of SendKeepaliveIfNecessary
>
> Try to send a keepalive message if too many changes was skipped.
>
> change to
>
> Try to send a keepalive message if too many changes wer skipped.
Fixed. Change 'was' to 'were'.

> 2. In pgoutput_change:
>
> + /* Reset the counter for skipped changes. */
> + SendKeepaliveIfNecessary(ctx, false);
> +
>
> This reset is called too early, this function might go on to skip
> changes because of the row filter, so this
> reset fits better once we know for sure that a change is sent out. You
> will also need to send keep alive
> when the change is skipped due to the row filter.
Fixed. Add a flag 'is_send' to record whether the change is sent, then reset
the counter or try to send a keepalive message based on the flag 'is_send'.

Attach the new patch.
1. Fix typo in comment on top of SendKeepaliveIfNecessary.[suggestion by Ajin.]
2. Add handling of cases filtered out by row filter.[suggestion by Ajin.]

Regards,
Wang wei

Attachment Content-Type Size
v2-0001-Fix-the-timeout-of-subscriber-in-long-transaction.patch application/octet-stream 14.2 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message wangw.fnst@fujitsu.com 2022-03-09 02:26:14 RE: Logical replication timeout problem
Previous Message David G. Johnston 2022-03-09 02:13:45 Re: Naming of the different stats systems / "stats collector"