Re: Replication slot stats misgivings - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: Replication slot stats misgivings
Date
Msg-id CAFiTN-vd44U_NYbCg-Wg=PaqEYQLDcKJfyqR77QfevAgLi0VxA@mail.gmail.com
Whole thread Raw
In response to Re: Replication slot stats misgivings  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
On Thu, Apr 22, 2021 at 7:52 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Wed, Apr 21, 2021 at 4:44 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> >
> > On Tue, Apr 20, 2021 at 7:54 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >
> > >
> > > I've attached the patch. In addition to the test Vignesh prepared, I
> > > added one test for the message for creating a slot that checks if the
> > > statistics are initialized after re-creating the same name slot.
> > > Please review it.
> >
> > Overall the patch looks good to me.  However, I have one question, I
> > did not understand the reason behind moving the below code from
> > "pgstat_reset_replslot_counter" to "pg_stat_reset_replication_slot"?
>
> Andres pointed out that pgstat_reset_replslot_counter() acquires lwlock[1]:
>
> ---
> - pgstat_reset_replslot_counter() acquires ReplicationSlotControlLock. I
> think pgstat.c has absolutely no business doing things on that level.
> ---
>
> I changed the code so that pgstat_reset_replslot_counter() doesn't
> acquire directly lwlock but I think that it's appropriate to do the
> existence check for slots in pgstatfunc.c rather than pgstat.c.

Thanks for pointing that out.  It makes sense to me.

-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Stale description for pg_basebackup
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Stale description for pg_basebackup