At Thu, 14 Nov 2019 12:01:29 +0900, Michael Paquier <michael@paquier.xyz> wrote in
> On Wed, Nov 13, 2019 at 09:17:03PM +0900, Michael Paquier wrote:
> > Actually, no, this is not good. I have been studying more the patch,
> > and after stressing more this code path with a cluster having
> > checksums enabled and shared_buffers at 1MB, I have been able to make
> > a couple of page's LSNs go backwards with pgbench -s 100. The cause
> > was simply that the page got flushed with a newer LSN than what was
> > returned by XLogSaveBufferForHint() before taking the buffer header
> > lock, so updating only the LSN for a non-dirty page was simply
> > guarding against that.
I thought of something like that but forgot to mention. But after
thinking of that, couldn't the current code can do the same think even
though with a far small probability? Still a session with smaller hint
LSN but didn't entered the header lock section yet can be cut-in by
another session with larger hint LSN.
> for the reference attached is the trick I have used, adding an extra
> assertion check in PageSetLSN().
I believe that all locations where Page-LSN is set is in the same
buffer-ex-lock section with XLogInsert.. but not sure.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
