RE: Failed transaction statistics to measure the logical replication progress - Mailing list pgsql-hackers

From wangw.fnst@fujitsu.com
Subject RE: Failed transaction statistics to measure the logical replication progress
Date
Msg-id OS3PR01MB6275B0ABA6D87650325FADAA9E3A9@OS3PR01MB6275.jpnprd01.prod.outlook.com
Whole thread Raw
In response to RE: Failed transaction statistics to measure the logical replication progress  ("osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>)
Responses RE: Failed transaction statistics to measure the logical replication progress
List pgsql-hackers
On Mon, Feb 21, 2022 11:46 AM Osumi, Takamichi/大墨 昂道 <osumi.takamichi@fujitsu.com> wrote:
>I've addressed this point in a new v23 patch, since there was no opinion on this so far.
>Kindly have a look at the attached one.
Thanks for updating the patch. Here is a comment:

In function apply_handle_stream_abort:
@@ -1217,6 +1219,7 @@ apply_handle_stream_abort(StringInfo s)
     {
         set_apply_error_context_xact(xid, 0);
         stream_cleanup_files(MyLogicalRepWorker->subid, xid);
+        pgstat_report_subworker_xact_end(false);
     }
     else
     {

I think there is a problem here, pgstat_report_stat is not invoked here.
While the other three places where function pgstat_report_subworker_xact_end is
invoked, the function pgstat_report_stat is invoked.
Do we need to invoke pgstat_report_stat in apply_handle_stream_abort?

Regards,
Wang wei

pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Patch a potential memory leak in describeOneTableDetails()
Next
From: Yura Sokolov
Date:
Subject: Re: Accommodate startup process in a separate ProcState array slot instead of in MaxBackends slots.