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

From vignesh C
Subject Re: Replication slot stats misgivings
Date
Msg-id CALDaNm0xxc-DhfQr-RdEKseCwPdojUDoy_yav7h_YvFXponPHw@mail.gmail.com
Whole thread Raw
In response to Re: Replication slot stats misgivings  (Andres Freund <andres@anarazel.de>)
Responses Re: Replication slot stats misgivings  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Tue, Mar 30, 2021 at 6:28 AM Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> On 2021-03-26 07:58:58 +0530, Amit Kapila wrote:
> > On Fri, Mar 26, 2021 at 1:17 AM Andres Freund <andres@anarazel.de> wrote:
> > > I suggest we wait doing anything about this until we know if the shared
> > > stats patch gets in or not (I'd give it 50% maybe). If it does get in
> > > things get a good bit easier, because we don't have to deal with the
> > > message loss issues anymore.
> > >
> >
> > Okay, that makes sense.
>
> Any chance you could write a tap test exercising a few of these cases?

I can try to write a patch for this if nobody objects.

> E.g. things like:
>
> - create a few slots, drop one of them, shut down, start up, verify
>   stats are still sane
> - create a few slots, shut down, manually remove a slot, lower
>   max_replication_slots, start up

Here by "manually remove a slot", do you mean to remove the slot
manually from the pg_replslot folder?

> IMO, independent of the shutdown / startup issue, it'd be worth writing
> a patch tracking the bytes sent independently of the slot stats storage
> issues. That would also make the testing for the above cheaper...

I can try to write a patch for this if nobody objects.

Regards,
Vignesh



pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Redundant errdetail prefix "The error was:" in some logical replication messages
Next
From: Ajin Cherian
Date:
Subject: Re: [PATCH] add concurrent_abort callback for output plugin