RE: Failed transaction statistics to measure the logical replication progress

On Friday, November 19, 2021 11:11 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> Besides that, I’m not sure how useful commit_bytes, abort_bytes, and
> error_bytes are. I originally thought these statistics track the size of received
> data, i.g., how much data is transferred from the publisher and processed on
> the subscriber. But what the view currently has is how much memory is used in
> the subscription worker. The subscription worker emulates
> ReorderBufferChangeSize() on the subscriber side but, as the comment of
> update_apply_change_size() mentions, the size in the view is not accurate:
...
> I guess that the purpose of these values is to compare them to total_bytes,
> stream_byte, and spill_bytes but if the calculation is not accurate, does it mean
> that the more stats are updated, the more the stats will be getting inaccurate?
Thanks for your comment !

I tried to solve your concerns about byte columns but there are really difficult issues to solve.
For example, to begin with the messages of apply worker are different from those of
reorder buffer.

Therefore, I decided to split the previous patch and make counter columns go first.
v14 was checked by pgperltidy and pgindent.

This patch can be applied to the PG whose commit id is after 8d74fc9 (introduction of
pg_stat_subscription_workers).

Best Regards,
Takamichi Osumi