Re: Skipping logical replication transactions on subscriber side

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Skipping logical replication transactions on subscriber side
Date: 2021-07-01 03:56:45
Message-ID: CAA4eK1LKOnJHjWUhmCwjGKtEZUYGf71_rNy-64W2tf_g5-b01A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 30, 2021 at 4:35 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Mon, Jun 28, 2021 at 10:12 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> >
> >
> > 0003 patch adds pg_stat_logical_replication_error statistics view
> > discussed on another thread[1]. The apply worker sends the error
> > information to the stats collector if an error happens during applying
> > changes. We can check those errors as follow:
> >
> > postgres(1:25250)=# select * from pg_stat_logical_replication_error;
> > subname | relid | action | xid | last_failure
> > ----------+-------+--------+-----+-------------------------------
> > test_sub | 16384 | INSERT | 736 | 2021-06-27 12:12:45.142675+09
> > (1 row)
> >
> > I added only columns required for the skipping transaction feature to
> > the view for now.
> >
>
> Isn't it better to add an error message if possible?
>

Don't we want to clear stats at drop subscription as well? We do drop
database stats in dropdb via pgstat_drop_database, so I think we need
to clear subscription stats at the time of drop subscription.

In the 0003 patch, if I am reading it correctly then the patch is not
doing anything for tablesync worker. It is not clear to me at this
stage what exactly we want to do about it? Do we want to just ignore
errors from tablesync worker and let the system behave as it is
without this feature? If we want to do anything then I think the way
to skip the initial table sync would be to behave like the user has
given 'copy_data' option as false.

--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2021-07-01 04:16:35 Re: postgres_fdw - should we tighten up batch_size, fetch_size options against non-numeric values?
Previous Message Amul Sul 2021-07-01 03:50:42 Re: New committers: Daniel Gustafsson and John Naylor