RE: Failed transaction statistics to measure the logical replication progress

From: "osumi(dot)takamichi(at)fujitsu(dot)com" <osumi(dot)takamichi(at)fujitsu(dot)com>
To: 'Masahiko Sawada' <sawada(dot)mshk(at)gmail(dot)com>
Cc: vignesh C <vignesh21(at)gmail(dot)com>, Greg Nancarrow <gregn4422(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: RE: Failed transaction statistics to measure the logical replication progress
Date: 2021-11-17 04:14:37
Message-ID: TYCPR01MB8373271BE5D4619302C05B00ED9A9@TYCPR01MB8373.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wednesday, November 17, 2021 12:19 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> On Tue, Nov 16, 2021 at 9:34 PM osumi(dot)takamichi(at)fujitsu(dot)com
> <osumi(dot)takamichi(at)fujitsu(dot)com> wrote:
> >
> > On Monday, November 15, 2021 9:14 PM I wrote:
> > > I've conducted some update for this.
> > > (The rebased part is only C code and checked by pgindent)
> > I'll update my patches since a new skip xid patch has been shared in
> > [1].
> >
> > This version includes some minor renames of functions that are related
> > to transaction sizes.
>
> I've looked at v12-0001 patch. Here are some comments:
Thank you for paying attention to this thread !

> - TupleDescInitEntry(tupdesc, (AttrNumber) 3, "relid",
> + TupleDescInitEntry(tupdesc, (AttrNumber) 3, "last_error_relid",
> OIDOID, -1, 0);
> - TupleDescInitEntry(tupdesc, (AttrNumber) 4, "command",
> + TupleDescInitEntry(tupdesc, (AttrNumber) 4, "last_error_command",
> TEXTOID, -1, 0);
> - TupleDescInitEntry(tupdesc, (AttrNumber) 5, "xid",
> + TupleDescInitEntry(tupdesc, (AttrNumber) 5, "last_error_xid",
> XIDOID, -1, 0);
> - TupleDescInitEntry(tupdesc, (AttrNumber) 6, "error_count",
> + TupleDescInitEntry(tupdesc, (AttrNumber) 6, "last_error_count",
> INT8OID, -1, 0);
> - TupleDescInitEntry(tupdesc, (AttrNumber) 7, "error_message",
> + TupleDescInitEntry(tupdesc, (AttrNumber) 7, "last_error_message",
>
> If renaming column names clarifies those meanings, the above changes should
> be included into my patch that introduces pg_stat_subscription_workers
> view?
At first, your column names of pg_stat_subscription_workers look totally OK to me by itself
and I thought I should take care of those renaming at the commit timing of my stats patches.
But, if you agree with the new names above and fixing your patch doesn't
bother you, I'd appreciate your help !

> I think that exporting PartitionTupleRouting should not be done in the one
> patch together with renaming the view columns. There is not relevance
> between them at all. If it's used by v12-0002 patch, I think it should be included
> in that patch or in another separate patch.
Yes, it's used by v12-0002.

Absolutely you are right. When you update the patch like above,
I would like to make it independent.

Best Regards,
Takamichi Osumi

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2021-11-17 04:58:46 Re: Skipping logical replication transactions on subscriber side
Previous Message Jeff Davis 2021-11-17 04:11:59 Re: Non-superuser subscription owners