Re: Failed transaction statistics to measure the logical replication progress

Поиск
Список
Период
Сортировка
От Masahiko Sawada
Тема Re: Failed transaction statistics to measure the logical replication progress
Дата
Msg-id CAD21AoDw4s=e7ES2y6+GW1A_aahzPCm4nk1qHw9Y+sqxQ5wmqQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Failed transaction statistics to measure the logical replication progress  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы RE: Failed transaction statistics to measure the logical replication progress  ("osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>)
Список pgsql-hackers
On Thu, Mar 24, 2022 at 12:30 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Thu, Mar 3, 2022 at 8:58 AM osumi.takamichi@fujitsu.com
> <osumi.takamichi@fujitsu.com> wrote:
> >
>
> This patch introduces two new subscription statistics columns
> (apply_commit_count and apply_rollback_count) to the
> pg_stat_subscription_stats view for counting cumulative transactions
> commits/rollbacks for a particular subscription. Now, users can
> already see the total number of xacts committed/rolled back in a
> particular database via pg_stat_database, so this can be considered
> duplicate information.

Right.

> OTOH, some users might be interested in the
> stats for a subscription to know how many transactions are
> successfully applied during replication because the information in
> pg_stat_database also includes the operations that happened on the
> node.

I'm not sure how useful this information is in practice. What can we
use this information for?

IIRC the original purpose of this proposed feature is to provide a way
for the users to understand the size and count of the succeeded and
failed transactions. At some point, the patch includes the statistics
of only the counts of commits, rollbacks, and errors. If new
statistics also include the size, it might be useful to achieve the
original goal. But I’m concerned that adding only apply_commit_count
and apply_rollback_count ends up adding the duplicate statistics with
no concrete use cases.

> I am not sure if it is worth adding this additional information or how
> useful it will be for users. Does anyone else want to weigh in on
> this?
>
> If nobody else sees value in this then I feel it is better to mark
> this patch as Returned with feedback or Rejected. We can come back to
> it later if we see more demand for this.

Marking as Returned with feedback makes sense to me.

Regards,

--
Masahiko Sawada
EDB:  https://www.enterprisedb.com/



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Corruption during WAL replay
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Corruption during WAL replay