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 по дате отправления:

Предыдущее
От: Daniel Gustafsson
Дата:
Сообщение: Re: Patch a potential memory leak in describeOneTableDetails()
Следующее
От: "wangsh.fnst@fujitsu.com"
Дата:
Сообщение: show schema.collate in explain(verbose on)