RE: Failed transaction statistics to measure the logical replication progress

Поиск
Список
Период
Сортировка
От wangw.fnst@fujitsu.com
Тема RE: Failed transaction statistics to measure the logical replication progress
Дата
Msg-id OS3PR01MB6275B0ABA6D87650325FADAA9E3A9@OS3PR01MB6275.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на RE: Failed transaction statistics to measure the logical replication progress  ("osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>)
Ответы RE: Failed transaction statistics to measure the logical replication progress  ("osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>)
Список 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 по дате отправления:

Предыдущее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: Patch a potential memory leak in describeOneTableDetails()
Следующее
От: Yura Sokolov
Дата:
Сообщение: Re: Accommodate startup process in a separate ProcState array slot instead of in MaxBackends slots.