On Sun, Mar 21, 2021 at 2:56 AM Andres Freund <and...@anarazel.de> wrote: > > On 2021-03-20 09:25:40 +0530, Amit Kapila wrote: > > On Sat, Mar 20, 2021 at 12:22 AM Andres Freund <and...@anarazel.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.
