Re: Skipping logical replication transactions on subscriber side
От | vignesh C |
---|---|
Тема | Re: Skipping logical replication transactions on subscriber side |
Дата | |
Msg-id | CALDaNm0XmW99qdRf52K+KhgOimf-roZp=W_zM0QE2i2dPnvy2g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Skipping logical replication transactions on subscriber side (Amit Kapila <amit.kapila16@gmail.com>) |
Список | pgsql-hackers |
On Fri, Nov 19, 2021 at 12:22 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Fri, Nov 19, 2021 at 11:09 AM vignesh C <vignesh21@gmail.com> wrote: > > > > On Fri, Nov 19, 2021 at 9:22 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > > > On Thu, Nov 18, 2021 at 5:10 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > > > > > > On Thu, Nov 18, 2021 at 5:45 PM tanghy.fnst@fujitsu.com > > > > <tanghy.fnst@fujitsu.com> wrote: > > > > > > > > > > On Tuesday, November 16, 2021 2:31 PM Masahiko Sawada <sawada.mshk@gmail.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: "WHEREsrsubstate <> 'r'") Is it intentional? I think this may cause a result that users don't know the statistics are stillexist, 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. Since we are passing true that Assert will not hit, sorry I missed to notice that. It will create a new entry as you rightly pointed out. Since the cleaning is handled by vacuum and current code is also doing that way, I felt no need to make any change. Regards, Vignesh
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Amit KapilaДата:
Сообщение: Re: Skipping logical replication transactions on subscriber side