Re: Design of pg_stat_subscription_workers vs pgstats

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Design of pg_stat_subscription_workers vs pgstats
Дата
Msg-id CAA4eK1LEoJ4V_CipAjJe+RJ+MSkVeqHqf=9qs-J3PbhKgFmjsQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Design of pg_stat_subscription_workers vs pgstats  ("David G. Johnston" <david.g.johnston@gmail.com>)
Ответы Re: Design of pg_stat_subscription_workers vs pgstats
Список pgsql-hackers
On Sat, Feb 19, 2022 at 10:35 PM David G. Johnston
<david.g.johnston@gmail.com> wrote:
>
> On Sat, Feb 19, 2022 at 9:37 AM Andres Freund <andres@anarazel.de> wrote:
>>
>> IMO the type of information you'd want for apply failures is substantially
>>
>> different enough from worker failures that I don't really see the temptation
>> to put them in the same table.
>>
>
> It's an error message and a transaction LSN in both cases right now, along with knowledge of whether said transaction
onlyaffects a single table (relid is not null) or not (relid is null).  Do you have a concrete idea in mind that would
makethis separation need more obvious? 
>

I would also like to mention that in some cases, sync workers also
behaves like apply worker (after initial sync till it catches up with
the apply worker) and try to stream and apply changes similar to apply
worker. The error during that phase will be no different than the
apply worker. One idea to make the separation more obvious is to
introduce 'worker_type' column similar to backend_type in
pg_stat_activity which will tell whether it is an apply worker or a
table sync worker.

--
With Regards,
Amit Kapila.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Design of pg_stat_subscription_workers vs pgstats
Следующее
От: Noboru Saito
Дата:
Сообщение: Separate the result of \watch for each query execution (psql)