Hi, On 2024-02-12 17:33:24 -0800, Jeff Davis wrote: > On Mon, 2024-02-12 at 15:36 -0800, Andres Freund wrote: > > > > It doesn't really seem like a necessary, or even particularly useful, > > part. You couldn't just call WALRead() for that, since the caller > > would need > > to know the range up to which WAL is valid but not yet flushed as > > well. Thus > > the caller would need to first use WaitXLogInsertionsToFinish() or > > something > > like it anyway - and then there's no point in doing the WALRead() > > anymore. > > I follow until the last part. Did you mean "and then there's no point > in doing the WaitXLogInsertionsToFinish() in WALReadFromBuffers() > anymore"?
Yes, not sure what happened in my brain there. > For now, should I assert that the requested WAL data is before the > Flush pointer or assert that it's before the Write pointer? Yes, I think that'd be good. > > Note that for replicating unflushed data, we *still* might need to > > fall back > > to reading WAL data from disk. In which case not asserting in > > WALRead() would > > just make it hard to find bugs, because not using > > WaitXLogInsertionsToFinish() > > would appear to work as long as data is in wal buffers, but as soon > > as we'd > > fall back to on-disk (but unflushed) data, we'd send bogus WAL. > > That makes me wonder whether my previous idea[1] might matter: when > some buffers have been evicted, should WALReadFromBuffers() keep going > through the loop and return the end portion of the requested data > rather than the beginning? I still doubt that that will help very often, but it'll take some experimentation to figure it out, I guess. > We can sort that out when we get closer to replicating unflushed WAL. +1 Greetings, Andres Freund
