At Thu, 14 Nov 2019 12:01:29 +0900, Michael Paquier <mich...@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
