On Thu, Mar 01, 2018 at 09:12:18AM +0800, Craig Ringer wrote: > On 1 March 2018 at 06:28, Justin Pryzby <pry...@telsasoft.com> wrote: > > The more fine grained these are the more useful they can be: > > > > Running with fsync=off is common advice while loading, so reporting that > > "fsync=off at some point" is much less useful than reporting "having to run > > recovery from an fsync=off database". > > > > I propose there could be two bits: > > > > 1. fsync was off at some point in history when the DB needed recovery; > > 2. fsync was off during the current instance; I assume the bit would be set > > whenever fsync=off was set, but could be cleared when the server was > > cleanly shut down. If the bit is set during recovery, the first bit > > would > > be permanently set. Not sure but if this bit is set and then fsync > > re-enabled, maybe this could be cleared after any checkpoint and not > > just > > shutdown ? > > > I think that's a very useful way to eliminate false positives and make this > diagnostic field more useful. But we'd need to guarantee that when you've > switched from fsync=off to fsync=on, we've actually fsync'd every extent of > every table and index, whether or not we think they're currently dirty and > whether or not the smgr currently has them open. Do something like initdb > does to flush everything. Without that, we could have WAL-vs-heap ordering > issues and so on *even after a Pg restart* if the system has lots of dirty > writeback to do.
I think a similar, "2 bit" scheme *could* be applied to full_page_writes, too. And the 2nd "soft" bit for FPW could also be cleared after checkpoint. I'd think that for FPW, previous checkpoints which had fsync=off wouldn't need special handling - so long as FPW=on, the "soft" bit can be cleared after successful checkpoint (as a micro-optimization, don't clear the "soft" bit if the "hard" bit is set). BTW this scheme has the amusing consequence that setting fsync=off should involve first writing+fsyncing these bits to pgcontrol. Justin