Re: Skipping logical replication transactions on subscriber side
Amit Kapila <amit.kapila16@gmail.com>
On Mon, Sep 27, 2021 at 11:02 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Mon, Sep 27, 2021 at 12:50 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >
> > On Mon, Sep 27, 2021 at 12:24 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> > > On Mon, Sep 27, 2021 at 6:21 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > > >
> > > > On Sat, Sep 25, 2021 at 4:23 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > > > >
> > > > > Sure, but each tablesync worker must have a separate relid. Why can't
> > > > > we have a single hash table for both apply and table sync workers
> > > > > which are hashed by sub_id + rel_id? For apply worker, the rel_id will
> > > > > always be zero (InvalidOId) and tablesync workers will have a unique
> > > > > OID for rel_id, so we should be able to uniquely identify each of
> > > > > apply and table sync workers.
> > > >
> > > > What I imagined is to extend the subscription statistics, for
> > > > instance, transaction stats[1]. By having a hash table for
> > > > subscriptions, we can store those statistics into an entry of the hash
> > > > table and we can think of subscription errors as also statistics of
> > > > the subscription. So we can have another hash table for errors in an
> > > > entry of the subscription hash table. For example, the subscription
> > > > entry struct will be something like:
> > > >
> > > > typedef struct PgStat_StatSubEntry
> > > > {
> > > > Oid subid; /* hash key */
> > > >
> > > > HTAB *errors; /* apply and table sync errors */
> > > >
> > > > /* transaction stats of subscription */
> > > > PgStat_Counter xact_commit;
> > > > PgStat_Counter xact_commit_bytes;
> > > > PgStat_Counter xact_error;
> > > > PgStat_Counter xact_error_bytes;
> > > > PgStat_Counter xact_abort;
> > > > PgStat_Counter xact_abort_bytes;
> > > > PgStat_Counter failure_count;
> > > > } PgStat_StatSubEntry;
> > > >
> > >
> > > I think these additional stats will be displayed via
> > > pg_stat_subscription, right? If so, the current stats of that view are
> > > all in-memory and are per LogicalRepWorker which means that for those
> > > stats also we will have different entries for apply and table sync
> > > worker. If this understanding is correct, won't it be better to
> > > represent this as below?
> >
> > I was thinking that we have a different stats view for example
> > pg_stat_subscription_xacts that has entries per subscription. But your
> > idea seems better to me.
>
> I mean that showing statistics (including transaction statistics and
> errors) per logical replication worker seems better to me, no matter
> what view shows these statistics. I'll change the patch in that way.
>
Sounds good.
--
With Regards,
Amit Kapila.
Commits
-
Test ALIGNOF_DOUBLE==4 compatibility under ALIGNOF_DOUBLE==8.
- c1da0acbb06e 15.0 landed
-
Reorder subskiplsn in pg_subscription to avoid alignment issues.
- 79b716cfb7a1 15.0 landed
-
Add ALTER SUBSCRIPTION ... SKIP.
- 208c5d65bbd6 15.0 landed
-
Optionally disable subscriptions on error.
- 705e20f8550c 15.0 cited
-
Update docs of logical replication for commit 8d74fc96db.
- 85c61ba8920b 15.0 landed
-
Respect permissions within logical replication.
- a2ab9c06ea15 15.0 cited
-
Fix regression test failure caused by commit 8d74fc96db.
- 41e66fee0516 15.0 landed
-
Add a view to show the stats of subscription workers.
- 8d74fc96db5f 15.0 landed
-
Add logical change details to logical replication worker errcontext.
- abc0910e2e0a 15.0 landed
-
Rename LOGICAL_REP_MSG_STREAM_END to LOGICAL_REP_MSG_STREAM_STOP.
- 4cd7a1896871 15.0 landed
-
Fix typo in protocol.sgml.
- e1915646658d 14.0 landed
- 0ac1aee0d7d8 15.0 landed
-
Remove unused argument in apply_handle_commit_internal().
- f4b939f1a372 14.0 landed
- 16bd4becee32 15.0 landed
-
Fix replication of in-progress transactions in tablesync worker.
- 0926e96c4934 14.0 cited
-
Reorder pg_sequence columns to avoid alignment issue
- f3b421da5f4a 10.0 cited