On Tue, May 19, 2020 at 4:31 PM Thomas Munro <thomas.mu...@gmail.com> wrote: > What would a precise version of this look like? Maybe we really only > need to fsync relation files that recovery modifies (as we already > do), plus those that it would have touched but didn't because of the > page LSN (a new behaviour to catch segment files that were written by > the last run but not yet flushed, which I guess in practice would only > happen with full_page_writes=off)? (If you were paranoid enough to > believe that the buffer cache were actively trying to trick you and > marked dirty pages clean and lost the error state so you'll never hear > about it, you might even want to rewrite such pages once.)
I suspect there was also a worry that perhaps we'd been running before with fsync=off, or that maybe we'd just created this data directory with a non-fsyncing tool like 'cp' or 'tar -xvf'. In normal cases we shouldn't need to be nearly that conservative, but it's unclear how we can know when it's needed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
