Re: Recovery of PGSQL after system crash failing!!!
От | Thomas Lockhart |
---|---|
Тема | Re: Recovery of PGSQL after system crash failing!!! |
Дата | |
Msg-id | 3A89DABB.19B030FA@alumni.caltech.edu обсуждение исходный текст |
Ответ на | RE: Recovery of PGSQL after system crash failing!!! (Ryan Kirkpatrick <pgsql@rkirkpat.net>) |
Ответы |
Re: Re: Recovery of PGSQL after system crash failing!!!
Re: Re: Recovery of PGSQL after system crash failing!!! |
Список | pgsql-hackers |
> 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
В списке pgsql-hackers по дате отправления: