RE: Skipping logical replication transactions on subscriber side - Mailing list pgsql-hackers

From osumi.takamichi@fujitsu.com
Subject RE: Skipping logical replication transactions on subscriber side
Date
Msg-id OSBPR01MB4888B3186514B19E125A27BEEDB29@OSBPR01MB4888.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Skipping logical replication transactions on subscriber side  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: Skipping logical replication transactions on subscriber side
List pgsql-hackers
On Thursday, September 30, 2021 2:45 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> I've attached updated patches that incorporate all comments I got so far. Please
> review them.
Hello


Minor two comments for v15-0001 patch.

(1) a typo in pgstat_vacuum_subworker_stat()

+               /*
+                * This subscription is live.  The next step is that we search errors
+                * of the table sync workers who are already in sync state. These
+                * errors should be removed.
+                */

This subscription is "alive" ?


(2) Suggestion to add one comment next to '0' in ApplyWorkerMain()

+                       /* report the table sync error */
+                       pgstat_report_subworker_error(MyLogicalRepWorker->subid,
+                                                                                 MyLogicalRepWorker->relid,
+                                                                                 MyLogicalRepWorker->relid,
+                                                                                 0,
+                                                                                 InvalidTransactionId,
+                                                                                 errdata->message);

How about writing /* no corresponding message type for table synchronization */ or something ?


Best Regards,
    Takamichi Osumi


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: psql - add SHOW_ALL_RESULTS option
Next
From: Justin Pryzby
Date:
Subject: Re: document the need to analyze partitioned tables