https://slinkov.ru/openforum/vsluhforumID3/1121.html Новых возможностей в PostgreSQL 7.2.3 не появилось, зато исправлено несколько очень серьезных ошибок в коде, приводящих, при определенных обстоятельствах, к потере данных в рамках транзакции. Разработчики советуют как можно скорее провести апгрейд, если у Вас используется 7.2.x версия PostgreSQL, тем более что dump/restore базы не требуется. Кратко список исправлений:[[END]]<br><br>&lt;li&gt;Ошибки в VACUUM коде, если VACUUM выполняется не под суперпользователем, то по ошибке могут быть удалены файлы где хранится лог текущих транзакций (pg_clog файлы);<br>&lt;li&gt;Поддержка дат до 1970 года при работе с новыми версиями glibc;<br>&lt;li&gt;Исправлена ошибка при shutdown'е приводящая к некорректному завершению;<br>&lt;li&gt;Ошибки приводящие к падению на SMP PPC машинах;<br>&lt;li&gt;pg_dump научился делать дампы "FULL JOIN USING".<br><br><br>URL: http://www.postgresql.org<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=1608<br><br> https://slinkov.ru/openforum/vsluhforumID3/1121.html#9 Tue, 19 Nov 2002 09:39:12 GMT &gt;У меня - тоже. Free + PostgreSQL. На одном процессоре. А на <br>&gt;SMP в реальной работе эту связку кто использует, а? Какие результаты? <br><br>Пользуемся, почти все нормально. FreeBSD, PostgreSQL 7.2.2. Объем - ~800000 записей.<br>Из проблем - периодически (от 0 до 5-7 раз в день) падает одно из соединений, предположительно, из-за ошибок в протоколе. В результате чего сервер сразу отключает всех остальных клиентов. Сделали автоматический reconnect при потере соединения у клиента.<br><br> https://slinkov.ru/openforum/vsluhforumID3/1121.html#8 Tue, 22 Oct 2002 07:53:37 GMT У меня - тоже. Free + PostgreSQL. На одном процессоре. А на SMP в реальной работе эту связку кто использует, а? Какие результаты?<br> https://slinkov.ru/openforum/vsluhforumID3/1121.html#7 Mon, 21 Oct 2002 06:38:55 GMT У меня FreeBSD 4.x и PostgerSQL 7.2.x работают<br>несколько месяцев.<br>Автоматическая заливка статистики с маршрутизаторов<br>CISCO (IP Accouning, Netflow).<br>Система в постоянной работе. Очень активной.<br>И все пучком... никаких проблем вообще не наблюдалось...<br>На сегодняшний день pgsql 7.2.3 на FreeBSD 4.7 P4-2000<br> https://slinkov.ru/openforum/vsluhforumID3/1121.html#6 Wed, 16 Oct 2002 06:18:18 GMT Кстати у нас PostgreSQL на Linux-e 2.4 Slackware 7.1 с SMP (2xP3-1000).<br> https://slinkov.ru/openforum/vsluhforumID3/1121.html#5 Tue, 15 Oct 2002 08:58:43 GMT &gt;Скорее всего у Вас алгоритм работы программы не <br>&gt;проработан.<br><br>Я тоже так думал, пока deadlock не стали вылазить на ровном месте и на самой простейшей таблице при апдейте без транзакции. Есть скрпипт который выполняет SELECT/UPDATE&#124;&#124;INSERT, скрипт запускается хаотично, вполне вероятна ситуация одновременного запуска. Но по идее PostgreSQL отлично справляется с этой ситауцией, мне кажется , что из-за SMP два управляющих фронтэнда PostgreSQL (при запуске на 2-процессорной системе) не разбирают ситуацию блокировки при одновременном запросе к обоим фронтэндам.<br><br>Про порядок следования операций с таблицами в пределах транзакции я в курсе, про тонкости описанные в LOCK-мануале тоже. <br><br>&gt;2 - 10) раз в секунду, без проблем. Вообще,если начинать работать <br>&gt;с БД, то лучше PostgreSQL, в перспективе, нет. <br><br>Согласен, но начинать мне поздно, я с PostgreSQL года с 1997 не расстаюсь, проблемы появились только на SMP машине.<br><br> https://slinkov.ru/openforum/vsluhforumID3/1121.html#4 Tue, 15 Oct 2002 08:50:13 GMT &gt;Какая у вас версия PostgreSQL? <br><br>7.2.1<br><br>&gt; У нас в промышленной эксплуатации 7.0.3, потом <br>&gt; перешли на 7.1 - все в полном порядке. <br><br>В том-то и дело, что при 7.0 и 7.1 проблем тоже небыло, хотя нагрузка на базу была намного меньше текущей.<br><br>&gt;1. Попробуйте PostgreSQL на классическом Linux-e (известно, что под FreeBSD он <br><br>У меня на SMP системе под FreeBSD, очень вероятно, что именно SMP и приводит к проблемам, так как на старом однопроцессорном сервере я deadlock'ов тоже не помню.<br><br><br><br> https://slinkov.ru/openforum/vsluhforumID3/1121.html#3 Tue, 15 Oct 2002 07:01:30 GMT Скорее всего у Вас алгоритм работы программы не <br>проработан. У меня десятки таблиц с кучей ФК и апдейтов несколько (~ 2 - 10) раз в секунду, без проблем. Вообще,если начинать работать с БД, то лучше PostgreSQL, в перспективе, нет.<br><br> https://slinkov.ru/openforum/vsluhforumID3/1121.html#2 Tue, 15 Oct 2002 06:40:49 GMT Какая у вас версия PostgreSQL? У нас в промышленной эксплуатации 7.0.3, потом перешли на 7.1 - все в полном порядке. Что касается deadlock: 1. Попробуйте PostgreSQL на классическом Linux-e (известно, что под FreeBSD он не очень хорошо себя показал, а под модифицированными ядрами Linux-a возможны проблемы). Итог - Slackware 8.1 + PostgreSQL 7.2.3 (собирать из исходников, все собирать с установками по-умолчанию). После такой кратко описанной установки надеюсь у вас заработает.<br> https://slinkov.ru/openforum/vsluhforumID3/1121.html#1 Mon, 14 Oct 2002 13:38:08 GMT <br>Интересно почему в PostgreSQL постоянно возникают deadlock. Причем для простейших таблиц (5 int полей с int ключем, 60 записей) с достаточно интенсивным UPDATE (примерно от 5 раз в минуту до 3 раз в сек.)- dead lock выскакивают регулярно, несмотря на ежедневный VACUUM ANALYZE и еженедельный VACUUM FULL базы. Запросы простейшие, даже транзакций нет. Просто постоянные SELECT и UPDATE, гораздо реже INSERT. <br><br>Раньше грешил на транзакции, dead lock вываливались на совершенно других базах, порядок следования доступа к таблицам был одинаковым.<br><br><br>