Re: Collect statistics about conflicts in logical replication

From: shveta malik <shveta(dot)malik(at)gmail(dot)com>
To: Peter Smith <smithpb2250(at)gmail(dot)com>
Cc: "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, shveta malik <shveta(dot)malik(at)gmail(dot)com>
Subject: Re: Collect statistics about conflicts in logical replication
Date: 2024-08-30 06:24:19
Message-ID: CAJpy0uDVhvL6omnp-zUOoeJnhFvxkKOMsf3cbaOu6ZfKJ6=EQw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 30, 2024 at 10:53 AM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
>
> Hi Hou-San. Here are my review comments for v4-0001.
>
> ======
>
> 1. Add links in the docs
>
> IMO it would be good for all these confl_* descriptions (in
> doc/src/sgml/monitoring.sgml) to include links back to where each of
> those conflict types was defined [1].
>
> Indeed, when links are included to the original conflict type
> information then I think you should remove mentioning
> "track_commit_timestamp":
> + counted only when the
> + <link linkend="guc-track-commit-timestamp"><varname>track_commit_timestamp</varname></link>
> + option is enabled on the subscriber.
>
> It should be obvious that you cannot count a conflict if the conflict
> does not happen, but I don't think we should scatter/duplicate those
> rules in different places saying when certain conflicts can/can't
> happen -- we should just link everywhere back to the original
> description for those rules.

+1, will make the doc better.

> ~~~
>
> 2. Arrange all the counts into an intuitive/natural order
>
> There is an intuitive/natural ordering for these counts. For example,
> the 'confl_*' count fields are in the order insert -> update ->
> delete, which LGTM.
>
> Meanwhile, the 'apply_error_count' and the 'sync_error_count' are not
> in a good order.
>
> IMO it makes more sense if everything is ordered as:
> 'sync_error_count', then 'apply_error_count', then all the 'confl_*'
> counts.
>
> This comment applies to lots of places, e.g.:
> - docs (doc/src/sgml/monitoring.sgml)
> - function pg_stat_get_subscription_stats (pg_proc.dat)
> - view pg_stat_subscription_stats (src/backend/catalog/system_views.sql)
> - TAP test SELECTs (test/subscription/t/026_stats.pl)
>
> As all those places are already impacted by this patch, I think it
> would be good if (in passing) we (if possible) also swapped the
> sync/apply counts so everything is ordered intuitively top-to-bottom
> or left-to-right.

Not sure about this though. It does not seem to belong to the current patch.

thanks
Shveta

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nisha Moond 2024-08-30 06:34:51 Re: Conflict Detection and Resolution
Previous Message shveta malik 2024-08-30 06:23:04 Re: Collect statistics about conflicts in logical replication