Hi all.
I've been back to this patch for a while recently. I witness that if a WAL
writer works fast, the already flushed WAL buffers will be zeroed out and
re-initialized for future use by AdvanceXLInsertBuffer in
XLogBackgroundFlush, so that WALReadFromBuffers will miss even though the
space of
Hi,
On Sat, Jun 8, 2024 at 5:24 PM Nitin Jadhav
wrote:
>
> I spent some time examining the patch. Here are my observations from the
review.
Thanks.
> - I believe there’s no need for an extra variable ‘nbytes’ in this
> context. We can repurpose the ‘count’ variable for the same function.
> If n
Hi Bharath,
I spent some time examining the patch. Here are my observations from the review.
- I believe there’s no need for an extra variable ‘nbytes’ in this
context. We can repurpose the ‘count’ variable for the same function.
If necessary, we might think about renaming ‘count’ to ‘nbytes’.
-
On Wed, May 8, 2024 at 9:51 AM Jingtang Zhang wrote:
>
> Hi, Bharath. I've been testing this. It's cool. Is there any way we could
> monitor the hit rate about directly reading from WAL buffers by exporting
> to some views?
Thanks for looking into this. I used purpose-built patches for
verifying
Hi, Bharath. I've been testing this. It's cool. Is there any way we could
monitor the hit rate about directly reading from WAL buffers by exporting
to some views?
---
Regards, Jingtang
