Re: Skipping logical replication transactions on subscriber side - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Skipping logical replication transactions on subscriber side
Date
Msg-id CAA4eK1K8Pe4s1E=RuEABEBWErpRxbeAw5M0CfE1Ux=yucYORfg@mail.gmail.com
Whole thread Raw
In response to RE: Skipping logical replication transactions on subscriber side  ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>)
Responses Re: Skipping logical replication transactions on subscriber side
List pgsql-hackers
On Wed, Nov 17, 2021 at 9:13 AM houzj.fnst@fujitsu.com
<houzj.fnst@fujitsu.com> wrote:
>
> On Tues, Nov 16, 2021 2:31 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> 2)
> +     <row>
> +      <entry role="catalog_table_entry"><para role="column_definition">
> +       <structfield>subrelid</structfield> <type>oid</type>
> +      </para>
> +      <para>
> +       OID of the relation that the worker is synchronizing; null for the
> +       main apply worker
> +      </para></entry>
> +     </row>
>
> Is the 'subrelid' only used for distinguishing the worker type ?
>

I think it will additionally tell which table sync worker as well.

> If so, would it
> be clear to have a string value here. I recalled the previous version patch has
> failure_source column but was removed. Maybe I missed something.
>

I also don't remember the reason for this but like to know.

I am also reviewing the latest version of the patch and will share
comments/questions sometime today.

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: "osumi.takamichi@fujitsu.com"
Date:
Subject: RE: Failed transaction statistics to measure the logical replication progress
Next
From: Michael Paquier
Date:
Subject: Re: Deficient error handling in pg_dump and pg_basebackup