RE: Failed transaction statistics to measure the logical replication progress - Mailing list pgsql-hackers

From osumi.takamichi@fujitsu.com
Subject RE: Failed transaction statistics to measure the logical replication progress
Date
Msg-id TYCPR01MB8373FEB287F733C81C1E4D42ED989@TYCPR01MB8373.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Failed transaction statistics to measure the logical replication progress  (vignesh C <vignesh21@gmail.com>)
Responses RE: Failed transaction statistics to measure the logical replication progress
List pgsql-hackers
On Thursday, November 11, 2021 9:47 PM vignesh C <vignesh21@gmail.com> wrote:
> Few more comments:
> 1) Here the tuple length is not considered in the calculation, else it will always
> show the fixed size for any size tuple. Ex varchar insert with 1 byte or varchar
> insert with 100's of bytes. So I feel we should include the tuple length in the
> calculation.
> +               case LOGICAL_REP_MSG_INSERT:
> +               case LOGICAL_REP_MSG_UPDATE:
> +               case LOGICAL_REP_MSG_DELETE:
> +                       Assert(extra_data != NULL);
> +
> +                       /*
> +                        * Compute size based on ApplyExecutionData.
> +                        * The size of LogicalRepRelMapEntry can be
> skipped because
> +                        * it is obtained from hash_search in
> logicalrep_rel_open.
> +                        */
> +                       size += sizeof(ApplyExecutionData) + sizeof(EState)
> +
> +                               sizeof(ResultRelInfo) +
> + sizeof(ResultRelInfo);
> +
> +                       /*
> +                        * Add some extra size if the target relation
> is partitioned.
> +                        * PartitionTupleRouting isn't exported.
> Therefore, call the
> +                        * function that returns its size instead.
> +                        */
> +                       if
> (extra_data->relmapentry->localrel->rd_rel->relkind ==
> RELKIND_PARTITIONED_TABLE)
> +                               size += sizeof(ModifyTableState) +
> PartitionTupleRoutingSize();
> +                       break;
Thanks a lot ! Fixed.


> 2) Can this be part of PgStat_StatDBEntry, similar to tables, functions and
> subworkers. It might be more appropriate to have it there instead of having
> another global variable.
> + * Stats of prepared transactions should be displayed
> + * at either commit prepared or rollback prepared time, even when it's
> + * after the server restart. We have the apply worker send those
> +statistics
> + * to the stats collector at prepare time and the startup process
> +restore
> + * those at restart if necessary.
> + */
> +static HTAB *subWorkerPreparedXactSizeHash = NULL;
> +
> +/*
Fixed. Also, its name was too long
when aligned with other PgStat_StatDBEntry memebers.
Thus I renamed it as subworkers_preparedsizes.

This depends on v21 in [1]

[1] - https://www.postgresql.org/message-id/CAD21AoAkd4YSoQUUFfpcrYOtkPRbninaw3sD0qc77nLW6Q89gg%40mail.gmail.com

Best Regards,
    Takamichi Osumi


Attachment

pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: Add connection active, idle time to pg_stat_activity
Next
From: Daniel Gustafsson
Date:
Subject: Re: Write visibility map during CLUSTER/VACUUM FULL