https://www.opennet.ru/openforum/vsluhforumID3/116581.html Сформированы (https://www.postgresql.org/about/news/1920/) корректирующие обновления для всех поддерживаемых веток PostgreSQL: 11.2 (https://www.postgresql.org/docs/current/static/release-11-2.html), 10.7 (https://www.postgresql.org/docs/current/static/release-10-7.html), 9.6.12 (http://www.postgresql.org/docs/current/static/release-9-6-12.html), 9.5.16 (http://www.postgresql.org/docs/current/static/release-9-5-16.html) и 9.4.21 (http://www.postgresql.org/docs/current/static/release-9-4-21.html), в которых исправлено около 70 ошибок. Наиболее значительным изменением стала переработка механизма использования вызова fsync() для обеспечения целостности записываемых на диск данных. <br><br><br><br>Оказалось (https://fosdem.org/2019/schedule/event/postgresql_fsync/), что вызов fsync() некорректно используется в PostgreSQL уже около 20 лет, что потенциально могло приводить к потере записываемых данных в случае аппаратных сбоев (проблема свойственна как Linux, так и некоторым BSD-системам). Разработчики PostgreSQL полагали, https://www.opennet.ru/openforum/vsluhforumID3/116581.html#102 Fri, 22 Feb 2019 11:27:48 GMT ну и чего теперь - владельцу сдохшего стора легче станет?<br><br>P.S. было б ниодного - мы бы хоть те патчи, что уже есть, пропихнули. Но там не принято коммитить через голову активно-копипастящего.<br> https://www.opennet.ru/openforum/vsluhforumID3/116581.html#101 Thu, 21 Feb 2019 16:01:21 GMT &gt; Если кто не понял - во freebsd _три_, прописью - три активных коммитера в zfs. Этот - один из.<br><br>Да хоть бы и ни одного не было. Оффсет, который zfs_blkptr_verify() сочла неправильным - это 72057594038013952 или 0x100000000015000, что выглядит как bitflip. <br> https://www.opennet.ru/openforum/vsluhforumID3/116581.html#100 Wed, 20 Feb 2019 10:58:52 GMT и база наверное должна навернуться, потому что.... кто то что-то удалил??!!<br> https://www.opennet.ru/openforum/vsluhforumID3/116581.html#99 Wed, 20 Feb 2019 10:56:57 GMT фатальное непонимание? LOL, давай продолжим - фатальное непонимание у разработчиков которые добавили эту олцию?!<br> https://www.opennet.ru/openforum/vsluhforumID3/116581.html#98 Wed, 20 Feb 2019 10:49:15 GMT Ностоящий девопс, паздравляю<br> https://www.opennet.ru/openforum/vsluhforumID3/116581.html#97 Tue, 19 Feb 2019 14:20:41 GMT а когда у него навернется база (причем не сразу, поэтому что там будет в среплицированных копиях - рандом его знает) - виноваты будем мы, ядро системы, что угодно, короче, кроме его фатального непонимания как именно субд взаимодействуют с этим самым ядром, в сочетании с беспокойными ручонками, которым лучше бы уж член и не выпускать :-(<br> https://www.opennet.ru/openforum/vsluhforumID3/116581.html#96 Tue, 19 Feb 2019 10:51:30 GMT Наверняка есть -- на что-то же должен этот SQL опираться. <br> https://www.opennet.ru/openforum/vsluhforumID3/116581.html#95 Tue, 19 Feb 2019 10:31:42 GMT &gt; Что за "Древние стандарты"?<br>&gt; Есть Posix, который умные люди расширяют, стандартизированно дорабатывают, и который гарантирует <br><br>позикс уже тоже дорасширяли до полной невменяемости.<br><br>&gt; что софт соберется практически везде.<br><br>такой сложный и ресурсожручий софт как postgres недостаточно собрать - он еще и работать после этого должен. А они только-только стали задумываться, что sysV ipc уже нигде толком немодно, да и с модными антипатчами типа kpti немодная многопроцессная вместо мультитредовой модель плохо совместима.<br><br> https://www.opennet.ru/openforum/vsluhforumID3/116581.html#94 Tue, 19 Feb 2019 09:05:35 GMT А есть ли у них интерфейс к данным мимо SQL, типа, как это у BerkeleyDB?<br>