https://www.opennet.dev/openforum/vsluhforumID3/77837.html Представлена (http://permalink.gmane.org/gmane.comp.db.postgresql.announce/1820) вторая бета-версия СУБД PostgreSQL 9.1 (http://www.postgresql.org/docs/9.1/static/release-9-1.html), в которой продолжена работа по выявлению и исправлению ошибок. Набор новшеств уже сформирован и до выпуска релиза меняться не будет. Релиз PostgreSQL 9.1 ожидается в течение лета. <br><br><br>Из ключевых улучшений PostgreSQL 9.1 можно отметить:<br><br><br><br><br><br>- Поддержка синхронной репликации (http://developer.postgresql.org/pgdocs/postgres/warm-standby.html#SYNCHRONOUS-REPLICATION), при которой запасной сервер (standby) будет содержать гарантированно совпадающие с основным сервером данные - до получения подтверждения записи синхронизированных данных транзакция не будет считаться завершенной. Ранее репликация на запасной сервер осуществлялась только в асинхронном режиме. Синхронную репликацию можно применять для отдельных транзакций, что позволяет комбинировать оба механизма, используя по умолчанию быстрый асинхронны...<br><br>URL: http://permali https://www.opennet.dev/openforum/vsluhforumID3/77837.html#29 Thu, 14 Jul 2011 09:47:58 GMT Кто-нибудь сравнивал по производительности с 8.4?<br> https://www.opennet.dev/openforum/vsluhforumID3/77837.html#28 Wed, 15 Jun 2011 16:52:49 GMT &gt; Для расширения кругозора попробуйте сравнить схему хранилища постгри с любой "серьезной" пропьетарщиной на рынке: Oracle, M$ (<br><br>Вы лучше вначале сами узнайте как же PITR работает во всех перечисленных продуктах. По секрету скажу, работает через те же самые редо (~WAL) логи. А почему именно так - учить мат. часть.<br><br>&gt; Таким образом, дизайн остается как есть, а как есть все транзакции со всех БД постгря валит в один несчастный wal, со всеми вытекающими в виде невозможности использования схем "Full+Inc&#124;Dif" для отдельной БД.<br><br>Чушь. В PG принципиальный дизайн точно такой же, как и во всех остальных СУБД. Постарайтесь таки посмотреть что делает pg-rman.<br><br>&gt; Но это надстройка, не меняющая сути. <br><br>Это пока стороний (а не надстройка) для PG продукт. Тут стоит посмотреть как многие из существующих фич в PG пришли из точно таких же стороних разработок.<br> https://www.opennet.dev/openforum/vsluhforumID3/77837.html#27 Wed, 15 Jun 2011 10:34:17 GMT А какой смысл в ожидании блокировки в начале транзакции? Раньше, до 9.1, если какие-то данные залочены в начале ли, или где-то посередине транзакции, другой транзакцией, транзакция вываливалась с serialization failure. По идее теперь с предикатными блокировками, такое будет происходить только в начале транзакции. Или как?<br> https://www.opennet.dev/openforum/vsluhforumID3/77837.html#26 Wed, 15 Jun 2011 07:45:25 GMT &gt; Это не регрессия, а защита от дурака. Выражение where v.t = t <br>&gt; неоднозначно по определению и не нужно его пытаться интерпретировать.<br><br> А по-моему однозначно, т.к. в объявлении функции я явно определил "t" в качестве аргумента, соответственно наверное знаю, что делаю. Восьмерка при этом определяла что-то типа "t := $1" и дальше пользовала "t" именно в таком качестве. Поэтому таки регрессия, т.к. отломали область имен в заголовках функций.<br> https://www.opennet.dev/openforum/vsluhforumID3/77837.html#25 Wed, 15 Jun 2011 07:24:57 GMT http://code.google.com/p/pg-rman/wiki/readme<br> Хорошая вещь. Но это надстройка, не меняющая сути. Для "Recovery to Point-in-Time" предлагается что бы Вы думали? Правильно, http://developer.postgresql.org/pgdocs/postgres/continuous-archiving.html<br> Таким образом, дизайн остается как есть, а как есть все транзакции со всех БД постгря валит в один несчастный wal, со всеми вытекающими в виде невозможности использования схем "Full+Inc&#124;Dif" для отдельной БД.<br><br> Для расширения кругозора попробуйте сравнить схему хранилища постгри с любой "серьезной" пропьетарщиной на рынке: Oracle, M$ (бывший Sybase, если правильно помню), IBM DB2 (ага, еще живой).<br> https://www.opennet.dev/openforum/vsluhforumID3/77837.html#24 Tue, 14 Jun 2011 16:36:22 GMT мастер мастер сделать нельзя. поменять местами мастер и слейв можно как и везде.<br> https://www.opennet.dev/openforum/vsluhforumID3/77837.html#23 Tue, 14 Jun 2011 16:35:04 GMT сериализация это немного другое<br> https://www.opennet.dev/openforum/vsluhforumID3/77837.html#22 Tue, 14 Jun 2011 16:28:20 GMT А можно ли с этой синхронной репликацией реализовать master-master?<br>При которой второй сервер всего лишь в режиме ожидания и получения данных, пока жив первый, принимает на себя работу когда первый упал и когда поднялся, то отдает ему первому данные, чтобы он потом стал главным опять.<br>На mysql это легко делается.<br> https://www.opennet.dev/openforum/vsluhforumID3/77837.html#21 Tue, 14 Jun 2011 15:41:52 GMT Кстати, я немного тестировал одно _универсальное_ High Available решение. Там есть основная требуемая функциональность в виде системы агентов, общей серверной части, возможность удаленного запуска скриптов через агенты и некоторые другие вещи. Нужно "допилить под себя" GUI (плагинная архитектура существенно упрощает этот процесс). Разработка опенсорсная (JBoss). Есть платный аналог, от Red Hat (ситуация как со взаимоотношением Fedora и RHEL, хотя на лично мой взгляд - в данном случае отличие не такое существенное, хотя я и тестировал/разбирался со всем мало).<br><br>Но как бы то ни было - в любой СУБД есть внутренний API, есть внутренние алгоритмы, оптимизированные для узкоспециализированных моментов. В том же Oracle через определенный интерфейс программирования - можно запрограммировать на С/С++ дополнительную функциональность для High Available, которую хочет именно ваша компания (помимо того, что есть вся функциональность "из каробки").<br><br>Вполне возможно, что "заточенное" решение даст от 20% и выше процент у