Сформированы (https://www.postgresql.org/about/news/1920/) корректирующие обновления для всех поддерживаемых веток PostgreSQL: 11.2 (https://www.postgresql.org/docs/current/static/release-11-2....), 10.7 (https://www.postgresql.org/docs/current/static/release-10-7....), 9.6.12 (http://www.postgresql.org/docs/current/static/release-9-6-12...), 9.5.16 (http://www.postgresql.org/docs/current/static/release-9-5-16...) и 9.4.21 (http://www.postgresql.org/docs/current/static/release-9-4-21...), в которых исправлено около 70 ошибок. Наиболее значительным изменением стала переработка механизма использования вызова fsync() для обеспечения целостности записываемых на диск данных.Оказалось (https://fosdem.org/2019/schedule/event/postgresql_fsync/), что вызов fsync() некорректно используется в PostgreSQL уже около 20 лет, что потенциально могло приводить к потере записываемых данных в случае аппаратных сбоев (проблема свойственна как Linux, так и некоторым BSD-системам). Разработчики PostgreSQL полагали, что успешно завершившийся вызов fsync() гарантирует, что поступившие данные записаны на постоянный носитель, но оказалось, что существуют ситуации когда это не так.
В случае когда ядро не может записать данные, например из-за сбоя буферизированного ввода/вывода вследствие аппаратной ошибки, некоторые операционные системы возвращают код ошибки в fsync() и очищают содержимое ожидающих записи буферов. Таким образом, ранее переданные данные отбрасываются, а блоки помечаются как очищенные. Получив код ошибки PostgreSQL опять попытается сбросить на диск данные и ещё раз вызывает fsync(). Так как буферы были очищены повторный вызов будет завершён успешно и PostgreSQL посчитает, что все данные записаны успешно. На деле, при чтении блоков, которые PostgreSQL полагает записанными, будет возвращено не то, что ожидается.
Начиная с выпусков PostgreSQL 11.2, 10.7, 9.6.12, 9.5.16 и 9.4.21 логика обработки ошибок fsync() изменена и PostgreSQL теперь не пытается после сбоя выполнения fsync() повторно вызвать fsync(), а завершается с выдачей фатальной ошибки. Данный шаг даёт возможность при перезапуске восстановить корректное состояние данных на основе WAL-лога, минуя скрытое повреждение содержимого базы. Подобная логика обработки ошибки может показаться неоптимальной, но разработчики сочли данное решение достаточным так как указанные проблемы возникают крайне редко.Для систем ядро которых не сбрасывает содержимое записи после сбоя в настройки добавлена опция data_sync_retry, позволяющая вернуть старое поведение с двойным вызовом fsync(). Можно отметить, что компания Google для обхода описанной проблемы использует альтернативный метод обработки ошибок ввода/вывода, основанный на сборе сведений об ошибках напрямую из ядра через netlink-сокет.
URL: https://www.postgresql.org/about/news/1920/
Новость: https://www.opennet.me/opennews/art.shtml?num=50148
а как с этим обстоят дела у оракала?
O_DIRECT и свой велосипед буферов.
> а как с этим обстоят дела у оракала?Тут не понятно, как оно "обстоит" к постреса-то, а ты про... проприертарь какую-то.
У постгреса fsync выключается одной строкой fsync = off.
У mysql пришлось исходники править т.к. O_DIRECT в итоге не отключал вызовы fsync.
я выключаю, у меня блок бесперебойного питания и потоковая репликация.
считаю что пусть этим занимается ядро системы а не ядро постгреса.
я выключал, потому что KMail тормозила :)
а когда у него навернется база (причем не сразу, поэтому что там будет в среплицированных копиях - рандом его знает) - виноваты будем мы, ядро системы, что угодно, короче, кроме его фатального непонимания как именно субд взаимодействуют с этим самым ядром, в сочетании с беспокойными ручонками, которым лучше бы уж член и не выпускать :-(
фатальное непонимание? LOL, давай продолжим - фатальное непонимание у разработчиков которые добавили эту олцию?!
и база наверное должна навернуться, потому что.... кто то что-то удалил??!!
Ностоящий девопс, паздравляю
Отлично, его же профессионалы делают.
> Можно отметить, что компания Google для обхода...А добавить свое решение в комьюнити они пробовали? пропиерасты
Может и пробовали. Ты думаешь так просто закоммиить в postgres? Ты знаешь сколько желающих запихнуть туда свой exstension, чтобы патчи самим не поддерживать.
> Ты думаешь так просто закоммиить в postgres?Олег Бартунов на одном из семинаров рассказывал, как это работает. Бывает, проходит несколько лет, пока патч не войдёт в основной релиз.
ты правда думаешь что в других опенсосных прожектах оно как-то иначе? Причем это несколько лет не пассивного ожидания щастья, а регулярных попыток разработчиков закрыть тикет notabug, советов куда тебе пойти и что еще им улучшить до того как они соизволят коснуться твоего грязного патча, ну и бесконечного его исправления в погоне за уходящим поездом апстрима (который тебе возможно нафиг не нужен, ибо ломает еще в десяти местах)Причем с весьма вероятным таки notabug, closed, comments allowed only from developers, через эти два года, вместо мержа.
встречаются исключения, где сперва принимают, а потом дают советы :)
> встречаются исключения, где сперва принимают, а потом дают советы :)Угрожая-то выносом из staging на мусорку? А не обращайте внимания -- это не про кодинг, платиновые взносы где-то подзадержались. "Трудности перевода."
>> Можно отметить, что компания Google для обхода...
> А добавить свое решение в комьюнити они пробовали? пропиерастыЭто ж он, бизнес _дружественный_ к опенсорсу.
Понимаете[I]?!
>А добавить свое решение в комьюнити они пробовали? пропиерастыОни тебе что-то должны? Ты сам не хочешь выложить все свои наработки (ха-ха) в открытый доступ?
А они свои наработки в общий доступ выкладывают не с целью денег заработать? А раз с целью заработать то и разговор другой.
А оно нужно?
Так ли уж часто БД будет менять файл в котором произошли сбои до того как БД его открыла?
Ну, при проблемах с диском лучше сразу умереть - это логично. Но интересно, какова мотивация сброса буферов? Кто-нибудь в курсе?
> Но интересно, какова мотивация сброса буферов? Кто-нибудь в курсе?Т.е. тебе рассказать зачем нужен fsync?
не, мне рассказать, зачем сбрасывать буфер если fsync не успешен
А, извини. Я думал ты неуч, а ты просто лентяй и даже новость не прочитал.
Я, конечно, тот ещё лентяй, но новость читал, и даже не раз, так как несколько обалдел от такого контринтуитивного поведения оси. Но да, сейчас добавили абзац об этом.
Стоп, всё равно непонятно. Ну ладно, произошла ошибка, зачем дальше позволять что-то в этот файл писать? Ну отбивать последующие write() с -1, да и всё...Не говоря о том, что ситуацию "из под фс выдернули носитель" не худо бы отслеживать и как-то осмысленно обрабатывать, тем более если это самый частый случай. В общем, правильно сказали - mess и есть.
> Не говоря о том, что ситуацию "из под фс выдернули носитель" не худо бы отслеживать и как-то
> осмысленно обрабатывать,freebsd по сей день очень "осмысленно" наворачивается в kernel panic.
У линукса чуть лучше - навсегда блокируется точка монтирования и та неудачливая fs которой оно принадлежало.Вот ЭТО сделать "как в винде" - то есть вывести юзеру сообщение "верни, козлина, флэшку на место, я ж еще не дописала" и таки попытаться дописать если вернет - с 1995го года нерешаемая задача, совершенно вот ну никак невозможно ее решить по тыщеодной причине, причина первая - не было пороха.
Ну ничего, зато щас запилим очередной "асинхронный инит", это как-то проще получается.
> freebsd по сей день очень "осмысленно" наворачивается в kernel panic.Пользуюсь флешками, киндлом, внешними хардами, подключаю телефон через usb, далеко не всегда не забываю отмонтировать. За последние 7 лет припоминаю ровно 0 паник. Странно.
пару лет назад у slw@ стабильно воспроизводилось банальным отключением виртуальной "дискеты" bhyve'омсомнительно чтобы с тех пор стало что-то сильно лучше.
> пару лет назад у slw@ стабильно воспроизводилось банальным отключением виртуальной "дискеты"
> bhyve'ом
> сомнительно чтобы с тех пор стало что-то сильно лучше.Есть архив подписки на stable за последние 4 год, с кучей репортов от slw@.
багрепорты от slw@
https://bugs.freebsd.org/bugzilla//buglist.cgi?emailcc2=1&em...
summary:crash || panic
comment: bhyve
https://bugs.freebsd.org/bugzilla//buglist.cgi?longdesc=bhyv... panic&query_format=advanced
везде 0 совпадений.
так что увы. Возможно бага в бихайве.
Не поленился, воткнул флешку (32GB, fat32), флешка подмонтировалась (1 кликом):
/dev/da0s1 on /media/da0s1 (msdosfs, local, nosuid, mounted by анонн)
сделал dd (^T и вытянул)
dd if=/dev/zero bs=1k > /media/da0s1/data
load: 0.32 cmd: dd 1327 [wswbuf0] 1.29r 0.00u 0.05s 0% 2024k
11520+0 records in
11520+0 records out
11796480 bytes transferred in 1.293887 secs (9117087 bytes/sec)
dd: stdout: Input/output error
50868+0 records in
50867+0 records out
52087808 bytes transferred in 2.649465 secs (19659746 bytes/sec)
флешка где-то через секунду отмонтировалась автоматически.Воткнул опять:
stat -x /media/da0s1/data
File: "/media/da0s1/data"
Size: 0 FileType: Regular File
выткнул, оно "само" отмонтировалось.
Пишу дальше, полет нормальный, щас вот капчу введу.
о, форма осталась в хистори. Попробуем так. Хотя впопеннет в очередной раз подтвердил что он - место для троллинга, а не дискуссий.> так что увы. Возможно бага в бихайве.
да нет, там все чотко было - удаляешь, шлеп... причем бы тут бхайв, если наворачивалось то что внутри? Просто хорошая и удобная тестовая схема.
другое дело что он тоже не будет терять время и заводить баги там, где не надеется ничего исправить, а в личной переписке я порылся - уже, походу, удалил (потому что мне тоже даром не надо - поржали и разошлись по своим делам).вот вам типичная реакция разработчика freebsd на багрепорт, когда человек не просто хихикая наблюдает 'и так у вас двадцать лет', а не поленился принести проблему на блюдечке (еще бы, у него, походу, не совсем бесполезный локалхост совсем помре):
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235683"кстати, это и вас, молодой человек, касается" - в смысле, пользователям ЭТОГО настоятельно задуматься о том, есть ли у вас запасной пул или можете ли вы его сотворить из воздуха если с рабочим случится вот такое. Причем это у него не физический диск сбойнул, это он так удачно по другому поводу панику поймал (cocococo-cow, multiple metadata, безопасТно!)
поскольку девизом "разработчиков" является "главное - ничего не чинить!"
а вам какой-то постгрез в ситуации когда и так уже "всьо пропало" кажется неправильным...
В оффтопике подобная ситуация называется багчек. Система дальше не работает, что бы не накуралесить.В FreeBSD это notabug, тогда с какой целью перезапуск?
> В оффтопике подобная ситуация называется багчек. Система дальше не работает, что бы
> не накуралесить.э... и вот стоишь ты такой весь красивый перед неработающей-чтоб системой - и чего делать-то будем?
> В FreeBSD это notabug, тогда с какой целью перезапуск?kern.panic_reboot_wait_time=-1 и будет "как в винде".
а дальше чо? Орать "люююди, помогите кто-нибудь"? Ну вот один, как видишь, орал - так к нему кровосос из соседнего болота вылез, щупальцами облизался и спрашивает - "ну я услышал, notabug, легче стало?" Еще и велел орать тише, а не то!
Если кто не понял - во freebsd _три_, прописью - три активных коммитера в zfs. Этот - один из.
(не в смысле все сломал, а в смысле - кроме него чинить просто некому вообще.)
> э... и вот стоишь ты такой весь красивый перед неработающей-чтоб системойО том и вопрос: а чей-та она не работает, нотабаг же?
> Если кто не понял - во freebsd _три_, прописью - три активных коммитера в zfs.
Тю. Тут ОС целиком исключительно _один_ человек разрабатывает полностью автономно.
> О том и вопрос: а чей-та она не работает, нотабаг же?так она работает - вон, отлично перезагружается. А хочешь какой другой работы - удали нафиг этот сторадж, создай новый - и все отлично дальше поедет. Какие еще данные, зачем они тебе были нужны?
> Тю. Тут ОС целиком исключительно _один_ человек разрабатывает полностью автономно.
это болгенос, что-ле? Так-то обычно чтобы вышло что-нибудь работающее, и пары тысяч не хватает. Откуда, собственно, и растет проблема.
>> Тю. Тут ОС целиком исключительно _один_ человек разрабатывает полностью автономно.
> это болгенос, что-ле?БолгенОС всего лишь принципиально новый софт. В Роза Ентерпрайз Десктоп новизна в этом плане отсутствует. Былые идеи развиты до исключительной автономии, как указано в реестре. Осталось дождаться, пока аутсорсер Билл получит гражданство РФ и подпишет загрузчик.
> Если кто не понял - во freebsd _три_, прописью - три активных коммитера в zfs. Этот - один из.Да хоть бы и ни одного не было. Оффсет, который zfs_blkptr_verify() сочла неправильным - это 72057594038013952 или 0x100000000015000, что выглядит как bitflip.
ну и чего теперь - владельцу сдохшего стора легче станет?P.S. было б ниодного - мы бы хоть те патчи, что уже есть, пропихнули. Но там не принято коммитить через голову активно-копипастящего.
> За последние 7 лет припоминаю ровно 0 паник. Странно.Брат, Аноним, ты явно делаешь что-то не так. :-)
>freebsd по сей день очень "осмысленно" наворачивается в kernel panic.Будьте добры привести PR.
Не надо "как в винде" (100500 руганей юзеру). Наоборот - надо уметь поймать, что устройства нет, отдавать какой-то осмысленный код ошибки приложениям, пытающимся что-то сделать с соответствующей фс и по тому же umount -f таки отмонтировать, а в контексте данной траблы - не убивать буферы, если устройство не исчезло.
Вы вообще то об одном и том же говорите. "Ругань юзеру" окошко - это и есть приложение, которое получает осмысленный код ошибки.По сути, меня в винде бесят их заблокированные файлы, которые без спецсредств и ребута ни удалить ни переместить. Маразм какой-то, запускаю раз в полгода поиграться, и постоянно на это наталкиваюсь, пытаясь какие-нибудь скриншоты сохранить и сгруппировать.
По сути, в линуксе бесит, что mount -f не работает часто. Накой черт он нужен тогда, или сделали бы как у гита, -f -f лол
не, у винды (той которая еще 95) окошко было системное (точнее не окошко, а свитч в текстмоду и вывод там предупреждения с abort/retry - а у нас для этого, вроде, пока еще есть - сислог)что в общем и целом - логично для юзерской системы - поскольку дает юзеру шанс исправить ситуацию вообще без потерь.
Ну а если "не совсем получилось" и мы в результате повисли - так хотя бы попытались, а результат тот же.> По сути, в линуксе бесит, что mount -f не работает часто.
он практически никогда не работает, кроме тех случаев, когда и без -f бы прокатило. Особенности unix vfs, проверенные веками и освященные традицией (даром что сам код написан с чистого листа), ничего не менять. Зато теперь у тебя ДВЕ проблемы - не отмонтирующаяся fs и зависшая консоль с umount ;-)
> Накой черт он нужен тогда, или сделали бы как у гита
уже есть - sysrq-s,u,b - поскольку результат, в общем-то, ровно тот же.
А остальное требует архитектурных изменений в vfs, на енто мы пойтить не могем, лучше system-ненужно258-d запилим с отдельным ядерным интерфейсом для него.
https://postgrespro.ru/docs/postgrespro/10/wal-configuration
Смотри чекпоинты
> Ну, при проблемах с диском лучше сразу умереть - это логично. Но
> интересно, какова мотивация сброса буферов? Кто-нибудь в курсе?В наука-и-жизни ж писали. На LWN-е то есть.
Они все _делают вид_, что в курсе. И каждый талдычит своё.
Непросвященным мирянам не понять.
для тех, кто держит реплики + с отставанием для защиты от дропов - это не важно
Диск может сбойнуть и на реплике, а из-за неспособности linux гарантировать fsync ваша реплика запишет на диск одно, а прочитает — другое. Получите потерю данных после promote на эту реплику.
Я одно не понял - а что предписывает fsync делать POSIX?
Реализация на усмотрение разработчиков ОС.https://www.opennet.me/man.shtml?topic=fsync&russian=5
"If the fsync() function fails, outstanding I/O operations are not guaranteed to have been completed."
Спасибо!А попадания в буфер (очередь?) входит в эти "I/O operations"?
Кажется, пора им этот пункт пересмотреть
> Кажется, пора им этот пункт пересмотреть[I]"" Пора прекратить этот разврат! -- и откопали позикс. ""
ребята из саппорта vmware рассказали что когда стали использовать постгрес для замены mssql то были очень удивлены "надёжностью" постгреса на линуксе, что mssql в ситуациях всяческих крэшей был надёжнее, со временем ситуация улучшилась, и сейчас врод бы как паритет, но вот, такой факт.
Эти ребята видимо режим надёжного хранения отключали, для скорости.
Всё гораздо хуже. Это не неправильное использование, а напрочь сломанный *sync().В контексте Постгреса: он использует процессы, а не треды. Один из процессов делает fsync(), заботясь только о своём сете данных. Упс, другой процесс уже не увидит ошибки от вызова fsync() со своей стороны. (теперь-то Постгрес запаникует, речь про раньше)
В глобальном контексте, касается любого приложения: делаете `sync` в шелле и... См. выше, ситуация аналогична.
как мне в свое время объяснял ank: 1. нельзя верить манам - их пишут не те кто писали код 2. если какое-то поведение не описано жестко в позиксе - значит, функция может вернуть что угодно, даже если не написано что она вообще что-то возвращает - достаточно и того что она не void 3. если у функции явно описаны возвращаемые коды ошибок, она может вернуть любой другойкак хотите, так и программируйте под ваш "новый стандарт".
это, надо понимать, какой-нибудь 99й или еще раньше.
P.S. с другой стороны - у тебя на ходу отвалился диск под базой. А потом еще и почему-то обратно привалился. Кто при этом думает, что база еще подлежит восстановлению - тот лох педальный.
> P.S. с другой стороны - у тебя на ходу отвалился диск под базой. А потом еще и почему-то обратно привалился. Кто при этом думает, что база еще подлежит восстановлению - тот лох педальный.Хе-хе-хе. Впрочем, "пох".
>>еще подлежит восстановлению - тот лох педальный.
> Хе-хе-хе. Впрочем, "пох".[I]Педальный!?
>>>еще подлежит восстановлению - тот лох педальный.
>> Хе-хе-хе. Впрочем, "пох".
> [I]Педальный!?Пардон? Лох или Пох?
Раскрою мыслю(голодный трезвого не разумеет :) ), проблему с pg + fsync один раз видел, база жива. Вот если бы wal помер, было бы интереснее.
> Раскрою мыслю(голодный трезвого не разумеет :) ), проблему с pg + fsync
> один раз видел, база жива. Вот если бы wal помер, было
> бы интереснее.ну а где подробности? В смысле - как ты дошел до жизни такой, что fsync отправил данные в /dev/null, и зачем еще потом пользуешься такой базой поверх такого стора?
>>>P.S. с другой стороны - у тебя на ходу отвалился диск под базой. А потом еще и почему-то обратно привалился. Кто при этом думает, что база еще подлежит восстановлению - тот лох педальный.А ты точно читал что там в талмудах про iSCSI написано?!?!?
Впрочем - пох! Причём педальный :-)))))
>>>>P.S. с другой стороны - у тебя на ходу отвалился диск под базой. А потом еще и почему-то обратно привалился. Кто при этом думает, что база еще подлежит восстановлению - тот лох педальный.
> А ты точно читал что там в талмудах про iSCSI написано?!?!?авторы большинства fs - точно не читали (их отчасти извиняет то, что это дерьмо придумано позже), поэтому буферы выбрасываются в унитаз, система гордо встает раком, а одна здорово распиаренная - вообще после этого начинает циклично перезагружаться, и хранилка восстановлению не подлежит, как мы недавно с изумлением узнали.
> Впрочем - пох! Причём педальный :-)))))
не, лох кто в 19м году использует iscsi вместо san, да еще и не имеет бэкапов, желательно вообще на другом типе стораджа.
Если совсем нет денег - используйте aoe (раз их совсем нет, у вас явно все в пределах соседней стойки уместилось, оно в такой ситуации вполне живо), не выпендривайтесь.
Ага, треды спасут :) Начнем с вопроса "а какие процессы в пг пишут на диск?".
Не спасут.
> В контексте Постгреса: он использует процессы, а не треды. Один из процессов делает fsync(), заботясь только о своём сете данных. Упс, другой процесс уже не увидит ошибки от вызова fsync() со своей стороны.Функция fsync() (https://pubs.opengroup.org/onlinepubs/009695399/functions/fs...) вызывается с конкретным файловым дескриптором, и просит ОС сбросить буферы только для него одного, так что всё что Вы написали про проблемы процессов PostgreSQL - это сугубо Ваши измышления и демонстрация Вашего же непонимания.
> В глобальном контексте, касается любого приложения: делаете `sync` в шелле и... См. выше, ситуация аналогична.
Не стоит путать функцию fsync() с одноимённой утилитой. Хотя, похоже, про то что утилита имеет параметры, Вы не знаете.
Не. Вот (по ссылке из новости же) детальнее: https://lwn.net/Articles/752063/
Тред читай по приведённой мной ссылке. Измышления у меня какие-то.
Хз, в общем, опасность (по личному опыту) преувеличена. Лично видел. БД не пострадала(хз, обычно wal отдельно!). Кейс с tablespace не рассматривался, вроде, еще наступят.
> В случае когда ядро Linux не может записать данные, например из-за сбоя буферизированного ввода/вывода вследствие аппаратной ошибки, некоторые операционные системы возвращают код ошибки в fsync() и очищают содержимое ожидающих записи буферов.что значит это предложение? "некоторые операционные системы" - это что?
>> В случае когда ядро
>>>например из-за
>>>>некоторые операционные системы
>>>>>содержимое ожидающих
> что значит это
>- это что?Драма ж. Беллетристика. сАспенс. Журнализм. </but stay tuned></dontouch that dial>
> что значит это предложение? "некоторые операционные системы" - это что?это что разработчики линукса начали отмазываться в стиле "а вон у netbsd вообще до сих пор негр дохлый висит, а у openbsd еще и каждый день - новый"
и тут до разработчиков постгреза (которые как раз категорически против "новых стандартов" и по сей день как-то неуклюже пытаются сохранить юникс-совместимость) начало потихоньку доходить... ;-)
> некоторые операционные системы возвращают код ошибки в fsync() и очищают содержимое ожидающих записи буферовТ.е. я правильно понимаю, это упомянутые операционные системы Linux, OpenBSD, NetBSD? А почему стесняетесь прямо сказать, стыдно? Что за "некоторые"?
> Т.е. я правильно понимаю, это упомянутые операционные системы Linux, OpenBSD, NetBSD? А
> почему стесняетесь прямо сказать, стыдно? Что за "некоторые"?Потому что они перечислены рядом в тексте новости. Незачем по нескольку раз одно и тоже копировать.
просто это не означает что список - исчерпывающий, вероятнее всего, к нему можно добавить еще много интересного.
А что ещё (хоть как то)живого осталось?
AIX, Solaris и Форточка ... а ну голубятня же ещё. Всио ...
Ну то есть "описано : неизвестно" = 4 : 4 ... :)
> А что ещё (хоть как то)живого осталось?
> AIX, Solaris и Форточка ... а ну голубятня же ещё. Всио ...ну постгрез, в силу любви к древним стандартам, все еще может собраться на чем-то мертвом.
И даже, наверное, как-то работать.Как у вас (ты ж, вроде, в .ca? ) со спросом на выгул собак, догситтинг, вот это вот всьо? В рай (по версии вашего премьера) при таком занятии, конечно, не возьмут, но и вляпаешься разьве что в легкоотмываемую какашку, а не в этот ваш мир занимательного софта.
и, заметь, нашествие скайнета и автоуправление искусственной идиотией этому бизнесу ни разу не угрожает.
Что за "Древние стандарты"?
Есть Posix, который умные люди расширяют, стандартизированно дорабатывают, и который гарантирует что софт соберется практически везде.
В отличие от "толпы отморозков" которые его выпилить пытаются не удосужившись даже изучить.
> Что за "Древние стандарты"?
> Есть Posix, который умные люди расширяют, стандартизированно дорабатывают, и который гарантируетпозикс уже тоже дорасширяли до полной невменяемости.
> что софт соберется практически везде.
такой сложный и ресурсожручий софт как postgres недостаточно собрать - он еще и работать после этого должен. А они только-только стали задумываться, что sysV ipc уже нигде толком немодно, да и с модными антипатчами типа kpti немодная многопроцессная вместо мультитредовой модель плохо совместима.
> Например, если ошибка ввода/вывода возникла до открытия файла, то fsync() завершится успешно.это ваще как?? кто-нить может объяснить что имелось в виду в этой строке?
>> Например, если ошибка ввода/вывода возникла до открытия файла, то fsync() завершится успешно.
> это ваще как?? кто-нить может объяснить что имелось в виду в этой
> строке?Robert Haas делает вид, что может. См. LWN и не морочьте нам голову, мы обсуждаем в новости и в дрвму.
1. в приложении: открыли, записали, закрыли (данные в кеше ФС)2. в консоли вызвали /bin/sync, получили ошибку
3. в приложении: открыли тот же файл, вызвали fsync(), linux возвращает 0, "всё записал", хотя данные из кеша всё ещё не записаны
А есть ли у них интерфейс к данным мимо SQL, типа, как это у BerkeleyDB?
Наверняка есть -- на что-то же должен этот SQL опираться.