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

From wangw.fnst@fujitsu.com
Subject RE: Logical replication timeout problem
Date
Msg-id OS3PR01MB62759AD2EE2B7CF8A8BB74599EC99@OS3PR01MB6275.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Logical replication timeout problem  (Peter Smith <smithpb2250@gmail.com>)
Responses Re: Logical replication timeout problem  (Peter Smith <smithpb2250@gmail.com>)
Re: Logical replication timeout problem  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Tues, Jan 24, 2023 at 8:28 AM Peter Smith <smithpb2250@gmail.com> wrote:
> Hi Hou-san, Here are my review comments for v5-0001.

Thanks for your comments.

> ======
> src/backend/replication/logical/reorderbuffer.c
> 
> 1.
> @@ -2446,6 +2452,23 @@ ReorderBufferProcessTXN(ReorderBuffer *rb,
> ReorderBufferTXN *txn,
>   elog(ERROR, "tuplecid value in changequeue");
>   break;
>   }
> +
> + /*
> + * Sending keepalive messages after every change has some overhead, but
> + * testing showed there is no noticeable overhead if keepalive is only
> + * sent after every ~100 changes.
> + */
> +#define CHANGES_THRESHOLD 100
> +
> + /*
> + * Try to send a keepalive message after every CHANGES_THRESHOLD
> + * changes.
> + */
> + if (++changes_count >= CHANGES_THRESHOLD)
> + {
> + rb->update_progress_txn(rb, txn, change);
> + changes_count = 0;
> + }
> 
> I noticed you put the #define adjacent to the only usage of it,
> instead of with the other variable declaration like it was before.
> Probably it is better how you have done it, but:
> 
> 1a.
> The comment indentation is incorrect.
> 
> ~
> 
> 1b.
> Since the #define is adjacent to its only usage IMO now the 2nd
> comment is redundant. So the code can just say
> 
>            /*
>             * Sending keepalive messages after every change has some
> overhead, but
>             * testing showed there is no noticeable overhead if
> keepalive is only
>             * sent after every ~100 changes.
>             */
> #define CHANGES_THRESHOLD 100
>             if (++changes_count >= CHANGES_THRESHOLD)
>             {
>                 rb->update_progress_txn(rb, txn, change);
>                 changes_count = 0;
>             }

Changed as suggested.

Attach the new patch.

Regards,
Wang Wei

Attachment

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Check lateral references within PHVs for memoize cache keys
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Time delayed LR (WAS Re: logical replication restrictions)