RE: Failed transaction statistics to measure the logical replication progress
От | osumi.takamichi@fujitsu.com |
---|---|
Тема | RE: Failed transaction statistics to measure the logical replication progress |
Дата | |
Msg-id | TYCPR01MB837332A087685B02E68A0751ED3A9@TYCPR01MB8373.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | RE: Failed transaction statistics to measure the logical replication progress ("wangw.fnst@fujitsu.com" <wangw.fnst@fujitsu.com>) |
Список | pgsql-hackers |
On Monday, February 21, 2022 6:06 PM Monday, February 21, 2022 6:06 PM wrote: > 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? Hi, I had tested this case before I posted the latest patch v23. It works when I call pg_stat_report_stat by other transaction. But, if we want to add pgstat_report_stat here, I need to investigate the impact of the addition. I'll check it and let you know. Best Regards, Takamichi Osumi
В списке pgsql-hackers по дате отправления: