On Fri, Apr 16, 2021 at 3:16 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Mon, Apr 12, 2021 at 2:57 PM vignesh C <vignes...@gmail.com> wrote: > > > > On Sat, Mar 20, 2021 at 9:26 AM Amit Kapila <amit.kapil...@gmail.com> 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. > > > > > > > I felt we can update the replication slot statistics data each time we > > spill/stream the transaction data instead of accumulating the > > statistics and updating at the end. I have tried this in the attached > > patch and the statistics data were getting updated. > > Thoughts? > > > > Did you check if we can update the stats when we release the slot as > discussed above? I am not sure if it is easy to do at the time of slot > release because this information might not be accessible there and in > some cases, we might have already released the decoding > context/reorderbuffer where this information is stored. It might be > okay to update this when we stream or spill but let's see if we can do > it easily at the time of slot release. >
I'm not sure if we will be able to update stats from here, as we will not have access to decoding context/reorderbuffer at this place, and also like you pointed out I noticed that the decoding context gets released earlier itself. Regards, Vignesh