URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 116581
[ Назад ]

Исходное сообщение
"Обновление PostgreSQL с устранением серьёзных проблем с fsync"

Отправлено opennews , 14-Фев-19 20:16 
Сформированы (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


Содержание

Сообщения в этом обсуждении
"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Аноним , 14-Фев-19 20:16 
а как с этим обстоят дела у оракала?

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено nobodynoone , 14-Фев-19 22:40 
O_DIRECT и свой велосипед буферов.

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Andrey Mitrofanov , 15-Фев-19 10:18 
> а как с этим обстоят дела у оракала?

Тут не понятно, как оно "обстоит" к постреса-то, а ты про...  проприертарь какую-то.


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Аноним , 15-Фев-19 10:57 
У постгреса fsync выключается одной строкой fsync = off.
У mysql пришлось исходники править т.к. O_DIRECT в итоге не отключал вызовы fsync.

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено одмин , 16-Фев-19 08:51 
я выключаю, у меня блок бесперебойного питания и потоковая репликация.
считаю что пусть этим занимается ядро системы а не ядро постгреса.

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Аноним , 16-Фев-19 10:24 
я выключал, потому что KMail тормозила :)

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено postgres , 19-Фев-19 17:20 
а когда у него навернется база (причем не сразу, поэтому что там будет в среплицированных копиях - рандом его знает) - виноваты будем мы, ядро системы, что угодно, короче, кроме его фатального непонимания как именно субд взаимодействуют с этим самым ядром, в сочетании с беспокойными ручонками, которым лучше бы уж член и не выпускать :-(

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено odmin , 20-Фев-19 13:56 
фатальное непонимание? LOL, давай продолжим - фатальное непонимание у разработчиков которые добавили эту олцию?!

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено odmin , 20-Фев-19 13:58 
и база наверное должна навернуться, потому что.... кто то что-то удалил??!!

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Онаним , 20-Фев-19 13:49 
Ностоящий девопс, паздравляю

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Аноним , 16-Фев-19 08:56 
Отлично, его же профессионалы делают.

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Аноним2 , 14-Фев-19 20:34 
>  Можно отметить, что компания Google для обхода...

А добавить свое решение в комьюнити они пробовали? пропиерасты


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Аноним , 14-Фев-19 22:15 
Может и пробовали. Ты думаешь так просто закоммиить в postgres? Ты знаешь сколько желающих запихнуть туда свой exstension, чтобы патчи самим не поддерживать.

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Анонимный прохожий , 15-Фев-19 09:36 
> Ты думаешь так просто закоммиить в postgres?

Олег Бартунов на одном из семинаров рассказывал, как это работает.  Бывает, проходит несколько лет, пока патч не войдёт в основной релиз.


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено нах , 15-Фев-19 11:49 
ты правда думаешь что в других опенсосных прожектах оно как-то иначе? Причем это несколько лет не пассивного ожидания щастья, а регулярных попыток разработчиков закрыть тикет notabug, советов куда тебе пойти и что еще им улучшить до того как они соизволят коснуться твоего грязного патча, ну и бесконечного его исправления в погоне за уходящим поездом апстрима (который тебе возможно нафиг не нужен, ибо ломает еще в десяти местах)

Причем с весьма вероятным таки notabug, closed, comments allowed only from developers, через эти два года, вместо мержа.


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Аноним , 16-Фев-19 10:47 
встречаются исключения, где сперва принимают, а потом дают советы :)

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Andrey Mitrofanov , 18-Фев-19 10:56 
> встречаются исключения, где сперва принимают, а потом дают советы :)

Угрожая-то выносом из staging на мусорку?  А не обращайте внимания -- это не про кодинг, платиновые взносы где-то подзадержались.  "Трудности перевода."


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Andrey Mitrofanov , 15-Фев-19 10:19 
>>  Можно отметить, что компания Google для обхода...
> А добавить свое решение в комьюнити они пробовали? пропиерасты

Это ж он, бизнес _дружественный_ к опенсорсу.

Понимаете[I]?!


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Qwerty , 15-Фев-19 11:03 
>А добавить свое решение в комьюнити они пробовали? пропиерасты

Они тебе что-то должны? Ты сам не хочешь выложить все свои наработки (ха-ха) в открытый доступ?


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено SAF0001 , 16-Фев-19 04:39 
А они свои наработки в общий доступ выкладывают не с целью денег заработать? А раз с целью заработать то и разговор другой.

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено КО , 15-Фев-19 12:22 
А оно нужно?
Так ли уж часто БД будет менять файл в котором произошли сбои до того как БД его открыла?

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Crazy Alex , 14-Фев-19 20:45 
Ну, при проблемах с диском лучше сразу умереть - это логично. Но интересно, какова мотивация сброса буферов? Кто-нибудь в курсе?

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Аноним , 14-Фев-19 21:17 
> Но интересно, какова мотивация сброса буферов? Кто-нибудь в курсе?

Т.е. тебе рассказать зачем нужен fsync?


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Crazy Alex , 14-Фев-19 21:24 
не, мне рассказать, зачем сбрасывать буфер если fsync не успешен

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Аноним , 14-Фев-19 21:40 
А, извини. Я думал ты неуч, а ты просто лентяй и даже новость не прочитал.

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Crazy Alex , 14-Фев-19 22:20 
Я, конечно, тот ещё лентяй, но новость читал, и даже не раз, так как несколько обалдел от такого контринтуитивного поведения оси. Но да, сейчас добавили абзац об этом.

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Crazy Alex , 14-Фев-19 22:30 
Стоп, всё равно непонятно. Ну ладно, произошла ошибка, зачем дальше позволять что-то в этот файл писать? Ну отбивать последующие write() с -1, да и всё...

Не говоря о том, что ситуацию "из под фс выдернули носитель" не худо бы отслеживать и как-то осмысленно обрабатывать, тем более если это самый частый случай. В общем, правильно сказали - mess и есть.


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено пох , 14-Фев-19 22:40 
> Не говоря о том, что ситуацию "из под фс выдернули носитель" не худо бы отслеживать и как-то
> осмысленно обрабатывать,

freebsd по сей день очень "осмысленно" наворачивается в kernel panic.
У линукса чуть лучше - навсегда блокируется точка монтирования и та неудачливая fs которой оно принадлежало.

Вот ЭТО сделать "как в винде" - то есть вывести юзеру сообщение "верни, козлина, флэшку на место, я ж еще не дописала" и таки попытаться дописать если вернет - с 1995го года нерешаемая задача, совершенно вот ну никак невозможно ее решить по тыщеодной причине, причина первая - не было пороха.

Ну ничего, зато щас запилим очередной "асинхронный инит", это как-то проще получается.


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено анонн , 14-Фев-19 22:53 
> freebsd по сей день очень "осмысленно" наворачивается в kernel panic.

Пользуюсь флешками, киндлом, внешними хардами, подключаю телефон через usb, далеко не всегда не забываю отмонтировать. За последние 7 лет припоминаю ровно 0 паник. Странно.


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено пох , 15-Фев-19 00:19 
пару лет назад у slw@ стабильно воспроизводилось банальным отключением виртуальной "дискеты" bhyve'ом

сомнительно чтобы с тех пор стало что-то сильно лучше.


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено анонн , 15-Фев-19 01:48 
> пару лет назад у 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

выткнул, оно "само" отмонтировалось.
Пишу дальше, полет нормальный, щас вот капчу введу.

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено пох , 15-Фев-19 07:58 
о, форма осталась в хистори. Попробуем так. Хотя впопеннет в очередной раз подтвердил что он - место для троллинга, а не дискуссий.

> так что увы. Возможно бага в бихайве.

да нет, там все чотко было - удаляешь, шлеп... причем бы тут бхайв, если наворачивалось то что внутри? Просто хорошая и удобная тестовая схема.
другое дело что он тоже не будет терять время и заводить баги там, где не надеется ничего исправить, а в личной переписке я порылся - уже, походу, удалил (потому что мне тоже даром не надо - поржали и разошлись по своим делам).

вот вам типичная реакция разработчика freebsd на багрепорт, когда человек не просто хихикая наблюдает 'и так у вас двадцать лет', а не поленился принести проблему на блюдечке (еще бы, у него, походу, не совсем бесполезный локалхост совсем помре):
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235683

"кстати, это и вас, молодой человек, касается" - в смысле, пользователям ЭТОГО настоятельно задуматься о том, есть ли у вас запасной пул или можете ли вы его сотворить из воздуха если с рабочим случится вот такое. Причем это у него не физический диск сбойнул, это он так удачно по другому поводу панику поймал (cocococo-cow, multiple metadata, безопасТно!)

поскольку девизом "разработчиков" является "главное - ничего не чинить!"

а вам какой-то постгрез в ситуации когда и так уже "всьо пропало" кажется неправильным...


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Аноним , 16-Фев-19 11:16 
В оффтопике подобная ситуация называется багчек. Система дальше не работает, что бы не накуралесить.

В FreeBSD это notabug, тогда с какой целью перезапуск?


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено пох , 16-Фев-19 12:16 
> В оффтопике подобная ситуация называется багчек. Система дальше не работает, что бы
> не накуралесить.

э... и вот стоишь ты такой весь красивый перед неработающей-чтоб системой - и чего делать-то будем?
> В FreeBSD это notabug, тогда с какой целью перезапуск?

kern.panic_reboot_wait_time=-1 и будет "как в винде".

а дальше чо? Орать "люююди, помогите кто-нибудь"? Ну вот один, как видишь, орал - так к нему кровосос из соседнего болота вылез, щупальцами облизался и спрашивает - "ну я услышал, notabug, легче стало?" Еще и велел орать тише, а не то!

Если кто не понял - во freebsd _три_, прописью - три активных коммитера в zfs. Этот - один из.
(не в смысле все сломал, а в смысле - кроме него чинить просто некому вообще.)


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Аноним , 16-Фев-19 16:04 
> э... и вот стоишь ты такой весь красивый перед неработающей-чтоб системой

О том и вопрос: а чей-та она не работает, нотабаг же?

> Если кто не понял - во freebsd _три_, прописью - три активных коммитера в zfs.

Тю. Тут ОС целиком исключительно _один_ человек разрабатывает полностью автономно.


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено пох , 16-Фев-19 20:20 
> О том и вопрос: а чей-та она не работает, нотабаг же?

так она работает - вон, отлично перезагружается. А хочешь какой другой работы - удали нафиг этот сторадж, создай новый - и все отлично дальше поедет. Какие еще данные, зачем они тебе были нужны?

> Тю. Тут ОС целиком исключительно _один_ человек разрабатывает полностью автономно.

это болгенос, что-ле? Так-то обычно чтобы вышло что-нибудь работающее, и пары тысяч не хватает. Откуда, собственно, и растет проблема.


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Аноним , 17-Фев-19 08:37 
>> Тю. Тут ОС целиком исключительно _один_ человек разрабатывает полностью автономно.
> это болгенос, что-ле?

БолгенОС всего лишь принципиально новый софт. В Роза Ентерпрайз Десктоп новизна в этом плане отсутствует. Былые идеи развиты до исключительной автономии, как указано в реестре. Осталось дождаться, пока аутсорсер Билл получит гражданство РФ и подпишет загрузчик.


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Anon Y Mous , 21-Фев-19 19:01 
> Если кто не понял - во freebsd _три_, прописью - три активных коммитера в zfs. Этот - один из.

Да хоть бы и ни одного не было. Оффсет, который zfs_blkptr_verify() сочла неправильным - это 72057594038013952 или 0x100000000015000, что выглядит как bitflip.


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено пох , 22-Фев-19 14:27 
ну и чего теперь - владельцу сдохшего стора легче станет?

P.S. было б ниодного - мы бы хоть те патчи, что уже есть, пропихнули. Но там не принято коммитить через голову активно-копипастящего.


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Анонимный прохожий , 15-Фев-19 09:40 
> За последние 7 лет припоминаю ровно 0 паник. Странно.

Брат, Аноним, ты явно делаешь что-то не так. :-)


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено universite , 15-Фев-19 00:11 

>freebsd по сей день очень "осмысленно" наворачивается в kernel panic.

Будьте добры привести PR.


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Crazy Alex , 15-Фев-19 05:53 
Не надо "как в винде" (100500 руганей юзеру). Наоборот - надо уметь поймать, что устройства нет, отдавать какой-то осмысленный код ошибки приложениям, пытающимся что-то сделать с соответствующей фс и по тому же umount -f таки отмонтировать, а в контексте данной траблы - не убивать буферы, если устройство не исчезло.

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Аноним , 15-Фев-19 06:43 
Вы вообще то об одном и том же говорите. "Ругань юзеру" окошко - это и есть приложение, которое получает осмысленный код ошибки.

По сути, меня в винде бесят их заблокированные файлы, которые без спецсредств и ребута ни удалить ни переместить. Маразм какой-то, запускаю раз в полгода поиграться, и постоянно на это наталкиваюсь, пытаясь какие-нибудь скриншоты сохранить и сгруппировать.

По сути, в линуксе бесит, что mount -f не работает часто. Накой черт он нужен тогда, или сделали бы как у гита, -f -f лол


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено пох , 15-Фев-19 07:52 
не, у винды (той которая еще 95) окошко было системное (точнее не окошко, а свитч в текстмоду и вывод там предупреждения с abort/retry - а у нас для этого, вроде, пока еще есть - сислог)

что в общем и целом - логично для юзерской системы - поскольку дает юзеру шанс исправить ситуацию вообще без потерь.
Ну а если "не совсем получилось" и мы в результате повисли - так хотя бы попытались, а результат тот же.

> По сути, в линуксе бесит, что mount -f не работает часто.

он практически никогда не работает, кроме тех случаев, когда и без -f бы прокатило. Особенности unix vfs, проверенные веками и освященные традицией (даром что сам код написан с чистого листа), ничего не менять. Зато теперь у тебя ДВЕ проблемы - не отмонтирующаяся fs и зависшая консоль с umount ;-)

> Накой черт он нужен тогда, или сделали бы как у гита

уже есть - sysrq-s,u,b - поскольку результат, в общем-то, ровно тот же.
А остальное требует архитектурных изменений в vfs, на енто мы пойтить не могем, лучше system-ненужно258-d запилим с отдельным ядерным интерфейсом для него.


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено rshadow , 14-Фев-19 21:43 
https://postgrespro.ru/docs/postgrespro/10/wal-configuration
Смотри чекпоинты

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Andrey Mitrofanov , 15-Фев-19 10:22 
> Ну, при проблемах с диском лучше сразу умереть - это логично. Но
> интересно, какова мотивация сброса буферов? Кто-нибудь в курсе?

В наука-и-жизни ж писали.  На LWN-е то есть.

Они все _делают вид_, что в курсе.  И каждый талдычит своё.

Непросвященным мирянам не понять.


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Аноним , 14-Фев-19 20:59 
для тех, кто держит реплики + с отставанием для защиты от дропов - это не важно

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Аноним , 16-Фев-19 02:37 
Диск может сбойнуть и на реплике, а из-за неспособности linux гарантировать fsync ваша реплика запишет на диск одно, а прочитает — другое. Получите потерю данных после promote на эту реплику.

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Аноним , 14-Фев-19 21:36 
Я одно не понял - а что предписывает fsync делать POSIX?

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Аноним , 14-Фев-19 21:46 
Реализация на усмотрение разработчиков ОС.

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."  


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Аноним , 14-Фев-19 21:54 
Спасибо!

А попадания в буфер (очередь?) входит в эти "I/O operations"?


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Аноним , 14-Фев-19 22:22 
Кажется, пора им этот пункт пересмотреть

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Andrey Mitrofanov , 15-Фев-19 10:31 
> Кажется, пора им этот пункт пересмотреть

[I]"" Пора прекратить этот разврат! -- и откопали позикс. ""


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено sdog , 14-Фев-19 23:10 
ребята из саппорта vmware рассказали что когда стали использовать постгрес для замены mssql то были очень удивлены "надёжностью" постгреса на линуксе, что mssql в ситуациях всяческих крэшей был надёжнее, со временем ситуация улучшилась, и сейчас врод бы как паритет, но вот, такой факт.

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Аноним , 16-Фев-19 02:42 
Эти ребята видимо режим надёжного хранения отключали, для скорости.

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено nobodynoone , 14-Фев-19 23:23 
Всё гораздо хуже. Это не неправильное использование, а напрочь сломанный *sync().

В контексте Постгреса: он использует процессы, а не треды. Один из процессов делает fsync(), заботясь только о своём сете данных. Упс, другой процесс уже не увидит ошибки от вызова fsync() со своей стороны. (теперь-то Постгрес запаникует, речь про раньше)

В глобальном контексте, касается любого приложения: делаете `sync` в шелле и... См. выше, ситуация аналогична.

https://www.postgresql.org/message-id/flat/CAMsr%2BYE5G...


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено пох , 15-Фев-19 00:25 
как мне в свое время объяснял ank: 1. нельзя верить манам - их пишут не те кто писали код 2. если какое-то поведение не описано жестко в позиксе - значит, функция может вернуть что угодно, даже если не написано что она вообще что-то возвращает - достаточно и того что она не void 3. если у функции явно описаны возвращаемые коды ошибок, она может вернуть любой другой

как хотите, так и программируйте под ваш "новый стандарт".

это, надо понимать, какой-нибудь 99й или еще раньше.

P.S. с другой стороны - у тебя на ходу отвалился диск под базой. А потом еще и почему-то обратно привалился. Кто при этом думает, что база еще подлежит восстановлению - тот лох педальный.


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Bx , 15-Фев-19 00:31 
> P.S. с другой стороны - у тебя на ходу отвалился диск под базой. А потом еще и почему-то обратно привалился. Кто при этом думает, что база еще подлежит восстановлению - тот лох педальный.

Хе-хе-хе. Впрочем, "пох".


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Andrey Mitrofanov , 15-Фев-19 10:34 
>>еще подлежит восстановлению - тот лох педальный.
> Хе-хе-хе. Впрочем, "пох".

[I]Педальный!?


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Bx , 16-Фев-19 03:30 
>>>еще подлежит восстановлению - тот лох педальный.
>> Хе-хе-хе. Впрочем, "пох".
> [I]Педальный!?

Пардон? Лох или Пох?
Раскрою мыслю(голодный трезвого не разумеет :) ), проблему с pg + fsync один раз видел, база жива. Вот если бы wal помер, было бы интереснее.


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено пох , 16-Фев-19 12:26 
> Раскрою мыслю(голодный трезвого не разумеет :) ), проблему с pg + fsync
> один раз видел, база жива. Вот если бы wal помер, было
> бы интереснее.

ну а где подробности? В смысле - как ты дошел до жизни такой, что fsync отправил данные в /dev/null, и зачем еще потом пользуешься такой базой поверх такого стора?


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено _ , 16-Фев-19 03:18 
>>>P.S. с другой стороны - у тебя на ходу отвалился диск под базой. А потом еще и почему-то обратно привалился. Кто при этом думает, что база еще подлежит восстановлению - тот лох педальный.

А ты точно читал что там в талмудах про iSCSI написано?!?!?
Впрочем - пох! Причём педальный :-)))))



"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено пох , 16-Фев-19 12:24 
>>>>P.S. с другой стороны - у тебя на ходу отвалился диск под базой. А потом еще и почему-то обратно привалился. Кто при этом думает, что база еще подлежит восстановлению - тот лох педальный.
> А ты точно читал что там в талмудах про iSCSI написано?!?!?

авторы большинства fs - точно не читали (их отчасти извиняет то, что это дерьмо придумано позже), поэтому буферы выбрасываются в унитаз, система гордо встает раком, а одна здорово распиаренная - вообще после этого начинает циклично перезагружаться, и хранилка восстановлению не подлежит, как мы недавно с изумлением узнали.

> Впрочем - пох! Причём педальный :-)))))

не, лох кто в 19м году использует iscsi вместо san, да еще и не имеет бэкапов, желательно вообще на другом типе стораджа.
Если совсем нет денег - используйте aoe (раз их совсем нет, у вас явно все в пределах соседней стойки уместилось, оно в такой ситуации вполне живо), не выпендривайтесь.


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Bx , 15-Фев-19 00:30 
Ага, треды спасут :) Начнем с вопроса "а какие процессы в пг пишут на диск?".

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено nobodynoone , 15-Фев-19 12:25 
Не спасут.

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено YetAnotherAnon , 15-Фев-19 02:40 
> В контексте Постгреса: он использует процессы, а не треды. Один из процессов делает fsync(), заботясь только о своём сете данных. Упс, другой процесс уже не увидит ошибки от вызова fsync() со своей стороны.

Функция fsync() (https://pubs.opengroup.org/onlinepubs/009695399/functions/fs...) вызывается с конкретным файловым дескриптором, и просит ОС сбросить буферы только для него одного, так что всё что Вы написали про проблемы процессов PostgreSQL - это сугубо Ваши измышления и демонстрация Вашего же непонимания.

> В глобальном контексте, касается любого приложения: делаете `sync` в шелле и... См. выше, ситуация аналогична.

Не стоит путать функцию fsync() с одноимённой утилитой. Хотя, похоже, про то что утилита имеет  параметры, Вы не знаете.


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Crazy Alex , 15-Фев-19 05:56 
Не. Вот (по ссылке из новости же) детальнее: https://lwn.net/Articles/752063/

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено nobodynoone , 15-Фев-19 12:24 
Тред читай по приведённой мной ссылке. Измышления у меня какие-то.

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Bx , 15-Фев-19 00:22 
Хз, в общем, опасность (по личному опыту) преувеличена. Лично видел. БД не пострадала(хз, обычно wal отдельно!). Кейс с tablespace не рассматривался, вроде, еще наступят.

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Аноним , 15-Фев-19 06:50 
> В случае когда ядро Linux не может записать данные, например из-за сбоя буферизированного ввода/вывода вследствие аппаратной ошибки, некоторые операционные системы возвращают код ошибки в fsync() и очищают содержимое ожидающих записи буферов.

что значит это предложение? "некоторые операционные системы" - это что?


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Andrey Mitrofanov , 15-Фев-19 10:39 
>> В случае когда ядро
>>>например из-за
>>>>некоторые операционные системы
>>>>>содержимое ожидающих
> что значит это
>- это что?

Драма ж. Беллетристика. сАспенс. Журнализм.  </but stay tuned></dontouch that dial>


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено нах , 15-Фев-19 12:51 
> что значит это предложение? "некоторые операционные системы" - это что?

это что разработчики линукса начали отмазываться в стиле "а вон у netbsd вообще до сих пор негр дохлый висит, а у openbsd еще и каждый день -  новый"

и тут до разработчиков постгреза (которые как раз категорически против "новых стандартов" и по сей день как-то неуклюже пытаются сохранить юникс-совместимость) начало потихоньку доходить... ;-)



"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Аноним , 15-Фев-19 10:24 
> некоторые операционные системы возвращают код ошибки в fsync() и очищают содержимое ожидающих записи буферов

Т.е. я правильно понимаю, это упомянутые операционные системы Linux, OpenBSD, NetBSD? А почему стесняетесь прямо сказать, стыдно? Что за "некоторые"?


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Аноним , 15-Фев-19 10:42 
> Т.е. я правильно понимаю, это упомянутые операционные системы Linux, OpenBSD, NetBSD? А
> почему стесняетесь прямо сказать, стыдно? Что за "некоторые"?

Потому что они перечислены рядом в тексте новости. Незачем по нескольку раз одно и тоже копировать.


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено нах , 15-Фев-19 12:53 
просто это не означает что список - исчерпывающий, вероятнее всего, к нему можно добавить еще много интересного.


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено _ , 16-Фев-19 03:22 
А что ещё (хоть как то)живого осталось?
AIX, Solaris и Форточка ... а ну голубятня же ещё. Всио ...
Ну то есть "описано : неизвестно" = 4 : 4  ... :)

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено пох , 16-Фев-19 12:30 
> А что ещё (хоть как то)живого осталось?
> AIX, Solaris и Форточка ... а ну голубятня же ещё. Всио ...

ну постгрез, в силу любви к древним стандартам, все еще может собраться на чем-то мертвом.
И даже, наверное, как-то работать.

Как у вас (ты ж, вроде, в .ca? ) со спросом на выгул собак, догситтинг, вот это вот всьо? В рай (по версии вашего премьера) при таком занятии, конечно, не возьмут, но и вляпаешься разьве что в легкоотмываемую какашку, а не в этот ваш мир занимательного софта.

и, заметь, нашествие скайнета и автоуправление искусственной идиотией этому бизнесу ни разу не угрожает.


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено bOOster , 18-Фев-19 17:07 
Что за "Древние стандарты"?
Есть Posix, который умные люди расширяют, стандартизированно дорабатывают, и который гарантирует что софт соберется практически везде.
В отличие от "толпы отморозков" которые его выпилить пытаются не удосужившись даже изучить.

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено пох , 19-Фев-19 13:31 
> Что за "Древние стандарты"?
> Есть Posix, который умные люди расширяют, стандартизированно дорабатывают, и который гарантирует

позикс уже тоже дорасширяли до полной невменяемости.

> что софт соберется практически везде.

такой сложный и ресурсожручий софт как postgres недостаточно собрать - он еще и работать после этого должен. А они только-только стали задумываться, что sysV ipc уже нигде толком немодно, да и с модными антипатчами типа kpti немодная многопроцессная вместо мультитредовой модель плохо совместима.


"Обновление PostgreSQL с устранением серьёзных проблем с fsync"
Отправлено J.L. , 15-Фев-19 12:32 
> Например, если ошибка ввода/вывода возникла до открытия файла, то fsync() завершится успешно.

это ваще как?? кто-нить может объяснить что имелось в виду в этой строке?


"Обновление PostgreSQL с устранением серьёзных проблем с fsync"
Отправлено Andrey Mitrofanov , 15-Фев-19 12:59 
>> Например, если ошибка ввода/вывода возникла до открытия файла, то fsync() завершится успешно.
> это ваще как?? кто-нить может объяснить что имелось в виду в этой
> строке?

Robert Haas делает вид, что может.  См. LWN и не морочьте нам голову, мы обсуждаем в новости и в дрвму.


"Обновление PostgreSQL с устранением серьёзных проблем с fsync"
Отправлено Аноним , 16-Фев-19 02:58 
1. в приложении: открыли, записали, закрыли (данные в кеше ФС)

2. в консоли вызвали /bin/sync, получили ошибку

3. в приложении: открыли тот же файл, вызвали fsync(), linux возвращает 0, "всё записал", хотя данные из кеша всё ещё не записаны


"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено Аноним , 19-Фев-19 12:05 
А есть ли у них интерфейс к данным мимо SQL, типа, как это у BerkeleyDB?

"Обновление PostgreSQL с устранением серьёзных проблем с fsyn..."
Отправлено adolfus , 19-Фев-19 13:51 
Наверняка есть -- на что-то же должен этот SQL опираться.