Re: Replication slot stats misgivings

On Sun, Mar 21, 2021 at 2:56 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> On 2021-03-20 09:25:40 +0530, Amit Kapila wrote:
> > On Sat, Mar 20, 2021 at 12:22 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > >
> > > And then more generally about the feature:
> > > - If a slot was used to stream out a large amount of changes (say an
> > > initial data load), but then replication is interrupted before the
> > > transaction is committed/aborted, stream_bytes will not reflect the
> > > many gigabytes of data we may have sent.
> > >
> >
> > We can probably update the stats each time we spilled or streamed the
> > transaction data but it was not clear at that stage whether or how
> > much it will be useful.
>
> It seems like the obvious answer here is to sync stats when releasing
> the slot?
>

Okay, that makes sense.

>
> > > - I seems weird that we went to the trouble of inventing replication
> > > slot stats, but then limit them to logical slots, and even there don't
> > > record the obvious things like the total amount of data sent.
> > >
> >
> > Won't spill_bytes and stream_bytes will give you the amount of data sent?
>
> I don't think either tracks changes that were neither spilled nor
> streamed? And if they are, they're terribly misnamed?
>

Right, it won't track such changes but we can track that as well and I
understand it will be good to track that information. I think we were
too focused on stats for newly introduced features that we forget
about the non-spilled and non-streamed xacts.

Note - I have now created an entry for this in PG14 Open Items [1].

[1] - https://wiki.postgresql.org/wiki/PostgreSQL_14_Open_Items

--
With Regards,
Amit Kapila.