Re: Logical replication timeout problem - Mailing list pgsql-hackers

From Ajin Cherian
Subject Re: Logical replication timeout problem
Date
Msg-id CAFPTHDZ+1hc060NALXUOkVSGQuqm9FUidiP6wex4-VHeZcP6_g@mail.gmail.com
Whole thread Raw
In response to RE: Logical replication timeout problem  ("wangw.fnst@fujitsu.com" <wangw.fnst@fujitsu.com>)
Responses RE: Logical replication timeout problem  ("wangw.fnst@fujitsu.com" <wangw.fnst@fujitsu.com>)
List pgsql-hackers
On Tue, Mar 8, 2022 at 12:25 PM wangw.fnst@fujitsu.com
<wangw.fnst@fujitsu.com> wrote:
> Attach the new patch.
> 1. Fix wrong variable setting and skip unnecessary time records.[suggestion by Kuroda-San and me.]
> 2. Introduce version information.[suggestion by Peter, Kuroda-San]
>
> Regards,
> Wang wei

Some 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.

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.

regards,
Ajin Cherian
Fujitsu Australia



pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: Expose JIT counters/timing in pg_stat_statements
Next
From: Peter Smith
Date:
Subject: Re: Optionally automatically disable logical replication subscriptions on error