[HACKERS] Re: Recovery of PGSQL after system crash failing!!!
It removes the need to disable fsync to get best performance! -F performance is still better, only the difference is not so big as before. Well, when "checkpoint seek in logs" will be implemented difference will be the same - lost consistency. Since there is a fundamental recovery problem if the WAL file disappears, then perhaps we should have a workaround which can ignore the requirement for that file on startup? Or maybe we do already? Vadim?? This was discussed, but iirc not yet implemented. Yes yes. Also, could the "-F" option be disabled now that WAL is enabled? Or is there still some reason to encourage/allow folks to use it? I've used it when testing btree runtime recovery to increase concurrence. I use it, since I restore after a system crash (which never happens). I think all that is probably missing in -F mode is probably 2-3 fsyncs during checkpoint. One for the xlog, and one for pg_control (maybe also pg_log). All other fsyncs are only to not buffer transactions. Probably we could just force fsync during checkpoint, for the moment. Thanks to all for help! Vadim
Re: [HACKERS] Re: Recovery of PGSQL after system crash failing!!!
Tom Lane writes: Thomas Lockhart [EMAIL PROTECTED] writes: Also, could the "-F" option be disabled now that WAL is enabled? Or is there still some reason to encourage/allow folks to use it? I was the one who put it back in after Vadim turned it off ;-) ... and I'll object to any attempt to remove the option. The description should be updated though: http://www.postgresql.org/devel-corner/docs/postgres/runtime-config.htm#RUNTIME-CONFIG-GENERAL I guess a lot of people have heard the rumour "PG 7.1 offers no-fsync performance with fsync turned on" and extrapolated "Imagine what it can do if I turn off fsync anyway." -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Re: Recovery of PGSQL after system crash failing!!!
Tom Lane writes: Thomas Lockhart [EMAIL PROTECTED] writes: Also, could the "-F" option be disabled now that WAL is enabled? Or is there still some reason to encourage/allow folks to use it? I was the one who put it back in after Vadim turned it off ;-) ... and I'll object to any attempt to remove the option. The description should be updated though: http://www.postgresql.org/devel-corner/docs/postgres/runtime-config.htm#RUNTIME-CONFIG-GENERAL I guess a lot of people have heard the rumour "PG 7.1 offers no-fsync performance with fsync turned on" and extrapolated "Imagine what it can do if I turn off fsync anyway." That is a very subtle point, and one I can imagine many people incorrectly assuming. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
[HACKERS] Re: Recovery of PGSQL after system crash failing!!!
Guilty as charged I am afraind... :( Here, I though with WAL and all (bad pun :), I would not need fsync anymore and decided to be reckless. Guess I ought to reconsider that decision Though wasn't WAL supposed to remove the need for fsync, or was it just to improve recovery ablity? It removes the need to disable fsync to get best performance! The converse is not true; it does not eliminate the need to fsync to help guard data integrity, and the WAL file management may be a bit less robust than that for other tables. I can see how this might have been omitted from much of the discussion, so it is important that we remind ourselves about this. Thanks for the reminder :/ Since there is a fundamental recovery problem if the WAL file disappears, then perhaps we should have a workaround which can ignore the requirement for that file on startup? Or maybe we do already? Vadim?? Also, could the "-F" option be disabled now that WAL is enabled? Or is there still some reason to encourage/allow folks to use it? - Thomas
Re: [HACKERS] Re: Recovery of PGSQL after system crash failing!!!
Thomas Lockhart [EMAIL PROTECTED] writes: Also, could the "-F" option be disabled now that WAL is enabled? Or is there still some reason to encourage/allow folks to use it? I was the one who put it back in after Vadim turned it off ;-) ... and I'll object to any attempt to remove the option. I think that there's no longer any good reason for people to consider -F in production use. On the other hand, for development or debugging work where you don't really *care* about powerfail survivability, I see no reason to incur extra wear on your disk drives by forcing fsyncs. My drives only have so many seeks left in 'em, and I'd rather see those seeks expended on writing source-code files than on fsyncs of test databases. regards, tom lane
