From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | vignesh C <vignesh21(at)gmail(dot)com> |
Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, "tanghy(dot)fnst(at)fujitsu(dot)com" <tanghy(dot)fnst(at)fujitsu(dot)com>, Greg Nancarrow <gregn4422(at)gmail(dot)com>, "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, "osumi(dot)takamichi(at)fujitsu(dot)com" <osumi(dot)takamichi(at)fujitsu(dot)com>, Alexey Lesovsky <lesovsky(at)gmail(dot)com>, 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-11-19 06:52:37 |
Message-ID: | CAA4eK1+1wkQ4a3hpAFUnrb+CwvHtyc_JPVqGaNMDm7n2LPXcJA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Nov 19, 2021 at 11:09 AM vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> On Fri, Nov 19, 2021 at 9:22 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Thu, Nov 18, 2021 at 5:10 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > >
> > > On Thu, Nov 18, 2021 at 5:45 PM tanghy(dot)fnst(at)fujitsu(dot)com
> > > <tanghy(dot)fnst(at)fujitsu(dot)com> wrote:
> > > >
> > > > On Tuesday, November 16, 2021 2:31 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > > > >
> > > > > Right. I've fixed this issue and attached an updated patch.
> > > > >
> > > > >
> > > >
> > > > Thanks for your patch.
> > > >
> > > > I read the discussion about stats entries for table sync worker[1], the
> > > > statistics are retained after table sync worker finished its jobs and user can remove
> > > > them via pg_stat_reset_subscription_worker function.
> > > >
> > > > But I notice that, if a table sync worker finished its jobs, the error reported by
> > > > this worker will not be shown in the pg_stat_subscription_workers view. (It seemed caused by this condition: "WHERE srsubstate <> 'r'") Is it intentional? I think this may cause a result that users don't know the statistics are still exist, and won't remove the statistics manually. And that is not friendly to users' storage, right?
> > > >
> > >
> > > You're right. The condition "WHERE substate <> 'r') should be removed.
> > > I'll do that change in the next version patch. Thanks!
> > >
> >
> > One more thing you might want to consider for the next version is
> > whether to rename the columns as discussed in the related thread [1]?
> > I think we should consider future work and name them accordingly.
> >
> > [1] - https://www.postgresql.org/message-id/CAA4eK1KR41bRUuPeNBSGv2%2Bq7ROKukS3myeAUqrZMD8MEwR0DQ%40mail.gmail.com
>
> Since the statistics collector process uses UDP socket, the sequencing
> of the messages is not guaranteed. Will there be a problem if
> Subscription is dropped and stats collector receives
> PGSTAT_MTYPE_SUBSCRIPTIONPURGE first and the subscription worker entry
> is removed and then receives PGSTAT_MTYPE_SUBWORKERERROR(this order
> can happen because of UDP socket). I'm not sure if the Assert will be
> a problem in this case.
>
Why that Assert will hit? We seem to be always passing 'create' as
true so it should create a new entry. I think a similar situation can
happen for functions and it will be probably cleaned in the next
vacuum cycle.
--
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | vignesh C | 2021-11-19 07:08:06 | Re: Skipping logical replication transactions on subscriber side |
Previous Message | Greg Nancarrow | 2021-11-19 06:32:23 | Re: Skipping logical replication transactions on subscriber side |