Рискну высказать свою точку зрения по поводу fsync-ов, хотя боюсь

на меня сейчас вылют ушат помоев:) Итак повторно sync-ать плохо - при этом может потеряться информация об ошибках записи. Ужас, ужас, ужас... Прощай ACID (С упало, D пропало, кто остался на трубе?)
Так, а из-за чего собственно ошибка то возникла? Может там диска сыпаться начал? А тогда не один ли хрен - накроется ли база сейчас или чуть попозже? Ну да, я конечно понимаю, что чем быстрее мы это обнаружим, тем быстрее мы сможем востановить базу из бэкапа (если он есть). И неверных ответов, основанных на битых данных, клиентам никто не зашлёт. И ещё есть вероятнось, что с дисков всё хоккей, "просто" на нём место кончилось. Тогда конечно не хорошо базу коррумпировать.

Это я всё к чему? К тому, что есть сферические кони в ваккуме. А есть жизнь. Есть вероятность отказа диска, есть вероятность багов в ОС, СУБД,... Причём последние зачастую сильно превышают вероятности "железных" багов, всякия прилетающие из космоса частицы и.т.п.
Тут было исследование, насколько хорошо современные диски и SSD переносят power failure и всегда ли заfsync-анные данные действительно в состоянии перенести жёсткое выключение. Выяснилось что чуть ли не половина моделей ведёт себя не правильно, причём не только теряет недавно записанные данные, но иногда и портит старые. Так что не надо рассматривать fsync как панацею...

А знаете как работает fsync на Amazon EDS?
Исключительно вероятностно. Они не пытаются честно засинкать данные на локальные диски. За счёт дублирования, они гарантируют, что вероятность потери данных меньше, чем для обычно диска с "честным" fsyncом...

Так что дествительно ли обнаруженная проблема сильно снижает надёность Посгреса? Не думаю...

Байка. Лет 10 назад, меня приглашали в один СУБД стартап, по написанию yet another pure Java OODBMS (у меня к тому времени была своя аналогичная). Так вот обсуждая с авторами особенности их архитектуры, а с удивлением узнал, что они не делают fsync-и. Вообще. Т.е. сливают Жавный файл кэш, и типо дело сделано. На мой вопль "№;%:?????, они спосоконо ответили, что пока никто из клиентов не жаловался, а fsync сильно тормозит работу. Продукт жмивёт до сих пор, но fsync-и я надеюсь туда всё таки прикрутили:)

В общем эта тема с fsync-ами конечно важная, поучительная, и.т.п. Но я бы всё таки не драматизировал. Ну и ес-но все эти разгоовры, о том что надо использовать O_DIRECT и всё будет чики-пыки или то, что кэш ОС только мешает нормальной работе СУБД, они немного от лукавого. Я на многих своих базках эксперементировал с O_DIRECT и в результате обычно получал значительное падаение скорости. Что не удивительно,Ю потому как только ОС знает сколько у неё в ланный момент действительно памяти свободно. На пользовательском уровне такой информации нет. Мы либо не используем имеющуюся память, либо, что ещё хуже, наш якобы "кэш", оказывается отсваппированным на диск. В Посгресе было много попыток избавится отдвойной буферизации. Но эффект от большинства из них был сомнителен.

Тут недавно взрослый mysql под названием oracle rdbms тестировали со вклбченным direct io. Система сидела в основном в диске. На тойже базе,но сконвертированной для postgres при тойже нагрузке дииски молчали.