<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
<channel>
	<title>Хабрахабр / PostgreSQL / Захабренные</title>
	<link>http://habrahabr.ru/rss/blog/postgresql/</link>
	<description><![CDATA[Захабренные посты из блога «PostgreSQL» на Хабрахабре]]></description>
	<language>ru</language>
	<managingEditor>editor@habrahabr.ru</managingEditor>
	<generator>habrahabr.ru</generator>
	<pubDate>Sat, 11 Feb 2012 09:06:27 GMT</pubDate>
	<lastBuildDate></lastBuildDate>
	<image>
		<link>http://habrahabr.ru/</link>
		<url>http://habrahabr.ru/i/logo.gif</url>
		<title>Хабрахабр</title>
	</image>
	
		
		
	<item>		
		<title><![CDATA[PostgreSQL / Отказ мастера в PostgreSQL-кластере: как быть?]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/postgresql/137932/</guid>
		<link>http://habrahabr.ru/blogs/postgresql/137932/</link>			
		<description><![CDATA[Приветствую. Сегодня я хотел бы поговорить о такой неприятной ситуации, как отказ мастера в случае применения нативной репликации в PostgreSQL 9.x. Итак, предположим, что у вас есть кластер из двух и более PostgreSQL-серверов и на мастер внезапно упал метеорит. Логично предположить, что вам придётся сделать мастером одну из реплик. Сделать это можно двумя способами. <div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/postgresql/137932/#habracut">Читать дальше &rarr;</a> </div>]]></description>
		
		<pubDate>Fri, 10 Feb 2012 00:11:25 GMT</pubDate>
		<author>mixermsk</author>
		<category>postgresql</category><category>replication</category><category>репликация</category><category>failover</category>
	</item>
	
	
	
	
	
	

		
	<item>		
		<title><![CDATA[PostgreSQL / Аудит таблиц с пространственными объектами в PostGIS/PostgreSQL]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/postgresql/137161/</guid>
		<link>http://habrahabr.ru/blogs/postgresql/137161/</link>			
		<description><![CDATA[<img src="http://postgis.refractions.net/download/logo_suite/stock_elephant/stock_elephant_060.gif" align="left" alt="image"/>В предыдущей <a href="http://habrahabr.ru/blogs/postgresql/137121/">статье</a> был рассмотрен пример с пространственными объектами и разделением доступа к ним по пользователям.<br/>
Теперь рассмотрим пример аудита данной базы. Нас интересует: кто, когда и что сделал с таблицей. Какую запись (читай «объект») добавил, какую удалил, какую изменил, чтобы в дальнейшем не было различных «недоразумений».<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/postgresql/137161/#habracut">Читать дальше &rarr;</a> </div>]]></description>
		
		<pubDate>Wed, 01 Feb 2012 05:41:43 GMT</pubDate>
		<author>pashtet51</author>
		<category>базы данных</category><category>postgresql</category><category>картография</category><category>гис</category>
	</item>
	
	
	
	
	
	

	
	
	
		
	<item>		
		<title><![CDATA[PostgreSQL / [Перевод] EnterpriseDB: мы заберём «свой кусок пирога» рынка СУБД у Oracle!]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/postgresql/137183/</guid>
		<link>http://habrahabr.ru/blogs/postgresql/137183/</link>
		<description><![CDATA[<img align="right" src="http://habrastorage.org/storage2/dc6/71d/f98/dc671df9887ecf6db33e89bb8906c7c9.jpg"/><i>Неделю назад компания EnterpriseDB анонсировала <a href="http://it.siteua.org/%D0%98%D0%A2-%D0%9D%D0%BE%D0%B2%D0%BE%D1%81%D1%82%D0%B8/332900/%D0%92%D1%8B%D1%88%D0%BB%D0%B0_%D0%BA%D0%BE%D1%80%D0%BF%D0%BE%D1%80%D0%B0%D1%82%D0%B8%D0%B2%D0%BD%D0%B0%D1%8F_%D0%BE%D0%B1%D0%BB%D0%B0%D1%87%D0%BD%D0%B0%D1%8F_%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D1%8F_EnterpriseDB_PostgreSQL">свой новый продукт — Postgres Plus Cloud Database</a> Я подумал, что неплохобы по этому поводу перевести что-нибудь о компании и её продуктах. Тем более, что с амбициями у руководителей там всё нормально — изображение справа с официального сайта enterprisedb. ;-) В некотором роде, данный перевод написан«в догонку» к <a href="http://habrahabr.ru/blogs/htranslations/136468/">«Oracle на пути к упадку»</a>.</i> <br/>
<br/>
В конце декабря компания Oracle сообщила о падении своих акций на 9%. Но мне эта новость не показалась удивительной, потому что всего за пару дней до её появления я беседовал с Эдом Бояджаном (Ed Boyajian), президентом и CEO компании EnterpriseDB.<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/postgresql/137183/#habracut">Читать дальше &rarr;</a> </div>]]></description>
		
		<pubDate>Sun, 29 Jan 2012 16:32:45 GMT</pubDate>
		<author>mister_fog</author>
		<category>postgresql</category><category>enterprisedb</category><category>oracle</category><category>субд</category><category>базы данных</category><category>sql</category>
	</item>
	
	
	

	
		
	<item>		
		<title><![CDATA[PostgreSQL / [Из песочницы] Организация хранения пространственных данных в PostGIS/PostgeSQL]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/postgresql/137121/</guid>
		<link>http://habrahabr.ru/blogs/postgresql/137121/</link>			
		<description><![CDATA[<img src="http://postgis.refractions.net/download/logo_suite/stock_elephant/stock_elephant_060.gif" align="left" alt="image"/>По приходу в одну контору, которая занимается разработкой карт, схем и планов, меня очень удивила одна вещь: не было централизованного хранилища всех материалов. Пользователи работали каждый со своими наработками. И если возникала потребность что-то взять из другого проекта – приходилось или бежать с «флэшечкой», или копировать файлы по сети. Что создавало неимоверное количество «мусора» в виде дубликатов разной свежести на множестве рабочих станций.<br/>
<br/>
После наблюдения всего этого хаоса, я решил все это дело «причесать» и сделать централизованным хранение картографического материала, с разграничением прав доступа к отдельным проектам, да еще и с мониторингом изменений, внесенных в проекты.<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/postgresql/137121/#habracut">Читать дальше &rarr;</a> </div>]]></description>
		
		<pubDate>Fri, 27 Jan 2012 10:12:23 GMT</pubDate>
		<author>pashtet51</author>
		<category>базы данных</category><category>postgresql</category><category>картография</category><category>гис</category>
	</item>
	
	
	
	
	

	
		
	<item>		
		<title><![CDATA[PostgreSQL / [Из песочницы] PostgreSQL: Уникальные ключи для распределенной базы. Практика]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/postgresql/136852/</guid>
		<link>http://habrahabr.ru/blogs/postgresql/136852/</link>			
		<description><![CDATA[По следам статьи <a href="http://habrahabr.ru/blogs/webdev/135364/">Уникальный ключ в условиях распределенной БД</a>. <br/>
<br/>
У нас есть база которую мы хотим разделить. В идеальном случае хочется сделать master-master. Один из самых сложных моментов, это обеспечение уникальности ключей на всех серверах. И хорошо если база изначально проектировалась с учетом масштабирования… Опять же, это что-то из области идеала, который встречается, скажем так — не часто.<br/>
<br/>
Итак у нас есть база которую нужно подготовить к синхронизации master-master — сделаем все ключи в нашей базе уникальными в пределах проекта.<br/>
<br/>
В упомянутой статье рассматривались несколько вариантов, но мы остановимся на одном предложенным <a href="http://instagram-engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram">Instagram</a><br/>
<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/postgresql/136852/#habracut">Читать дальше &rarr;</a> </div>]]></description>
		
		<pubDate>Mon, 23 Jan 2012 18:01:27 GMT</pubDate>
		<author>Borgius</author>
		<category>postgresql</category><category>sql</category><category>autoincrement</category><category>primary key</category><category>unique key</category><category>Instagram</category>
	</item>
	
	
	
	
	

	
		
	<item>		
		<title><![CDATA[PostgreSQL / [Из песочницы] Создание тестера для нагрузочного тестирования PostgreSQL]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/postgresql/133994/</guid>
		<link>http://habrahabr.ru/blogs/postgresql/133994/</link>			
		<description><![CDATA[Идея этого проектика (именно «проектика») возникла спонтанно. В компании используется memory-DB TimesTen, содержит одну большую таблицу с данными, более 150 млн записей, и объем около 15 гигов. TimesTen всегда работал исправно, ответ по любому запросу получали за считанные миллисекунды, всех это устраивало. В один из дней, T10 стал отвечать на запросы очень долго, время ответа увеличилось до 3-5 секунд. Техподдрежка конечно начала проведение работ по поиску проблемы, но параллельно мы задались вопросом, а для чего вообще используется T10, почему нельзя перенести базу на обычную СУРБД Oracle или Postgres?<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/postgresql/133994/#habracut">Читать дальше &rarr;</a> </div>]]></description>
		
		<pubDate>Mon, 05 Dec 2011 08:17:21 GMT</pubDate>
		<author>Mar4elo</author>
		<category>PostgreSQL</category><category>постгрес</category><category>тестирование</category><category>производительность</category><category>субд</category>
	</item>
	
	
	
	
	

		
	<item>		
		<title><![CDATA[PostgreSQL / Экстремальное тестирование streaming репликации PostgreSQL 9.1]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/postgresql/133755/</guid>
		<link>http://habrahabr.ru/blogs/postgresql/133755/</link>			
		<description><![CDATA[<img src="http://andyhost.ru/images/bober_l.jpg" alt="image" align="left"/>Возникла задача внедрения streaming репликации Postgresql 9.1 на продакшене. А т.к. раньше с нею дела не имели, решили провести ее «эстремальное тестирование».<br/>
<br/>
Для этого были запущены две виртуальные машины VMWare Player с Ubuntu Server. Установлена и настроена streaming репликация на Postgresql 9.1.<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/postgresql/133755/#habracut">Читать дальше &rarr;</a> </div>]]></description>
		
		<pubDate>Thu, 01 Dec 2011 09:14:54 GMT</pubDate>
		<author>UncleAndy</author>
		<category>postgresql</category><category>репликация</category><category>тестирование</category><category>fsync</category>
	</item>
	
	
	
	
	
	

		
	<item>		
		<title><![CDATA[PostgreSQL / Watchdog для репликации в PostgreSQL 9]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/postgresql/130704/</guid>
		<link>http://habrahabr.ru/blogs/postgresql/130704/</link>			
		<description><![CDATA[Приветствую. Хочу поделиться одним самописным костылём, авось кому-нибудь будет полезен. <br/>
<br/>
<h4>Коротко о главном</h4><br/>
Моделируем ситуацию: есть кластер PostgreSQL-серверов — мастер и n-реплик. Наступает черный день и одна(или несколько) реплик падает. Причины неважны — сдохла железка, уборщица перебила шваброй провод или НЛО временно зохавало серверную. Итог один — если реплика долго лежала, то сама она уже никогда не нагонится. <div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/postgresql/130704/#habracut">Читать дальше &rarr;</a> </div>]]></description>
		
		<pubDate>Tue, 18 Oct 2011 20:08:31 GMT</pubDate>
		<author>mixermsk</author>
		<category>postgresql 9.0</category><category>postgresql</category><category>костыль</category><category>костыли</category><category>репликация</category>
	</item>
	
	
	
	
	
	

		
	<item>		
		<title><![CDATA[PostgreSQL / Когда триггерная репликация предпочтительнее встроенной в PostgreSQL]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/postgresql/130515/</guid>
		<link>http://habrahabr.ru/blogs/postgresql/130515/</link>			
		<description><![CDATA[С 9.0 версии PostgreSQL есть встроенный механизм Master-Slave репликации (streaming replication).<br/>
Однако, с его появлением выбрасывать старые триггерные механизмы не следует.<br/>
<br/>
В общем случае, если нам требуется нечто большее, чем одна абсолютно точная копия всего DB-сервера, то триггеры остаются с нами.<br/>
<br/>
Примеры таких ситуаций:<br/>
<ul>
<li>Если требуется failover (т.е. останавливается Master и все запросы временно идут на Slave, а потом запущенный Master начинает догоняется до актуального состояния со Slave).</li>
<li>Master и Slave не являются 1:1 идентичными. Например, по какой-то причине на Slave надо держать дополнительные данные (базы/таблицы) или же копированию с Master подлежат не все базы/таблицы, или же при удалении данных — они должны сохраниться на Slave.</li>
<li>В проекте приходится использовать продуктовый «зоопарк» — т.е. Master и Slave имеют по какой-то причине разные версии, или же версии одинаковые, но ОС разной «битности».</li>
<li>В проекте требуется рекурсивная репликация Master-Slave1-Slave2-Slave3 или в реально нагруженном INSERT/UPDATE проекте к Master параллельно подключается больше, чем 1 Slave (хотя некоторые проекты имеют нагрузку, с которой могут нормально работать и до 5-6 Slave).</li>
<li>Если по какой-то причине требуются различные права доступа к объектам базы на Master и Slave.</li>
</ul><br/>
<br/>
Добавляйте в комментариях дополнительные варианты.<br/>
<br/>
Примечание: Возможность построения failover задекларирована месяц назад в версии 9.1 под названием «Synchronous Replication». Однако, лично я пока ещё эксперименты не проводил.]]></description>
		
		<pubDate>Sun, 16 Oct 2011 14:20:40 GMT</pubDate>
		<author>gis</author>
		<category>PostgreSQL</category><category>репликация</category><category>streaming</category><category>триггеры</category>
	</item>
	
	
	
	
	
	

		
	<item>		
		<title><![CDATA[PostgreSQL / Немного о деревьях]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/postgresql/130371/</guid>
		<link>http://habrahabr.ru/blogs/postgresql/130371/</link>			
		<description><![CDATA[<h4>Вступление</h4><br/>
Встречалась ли вам ситуация, когда необходимо реализовать хранение древовидной структуры в реляционной БД?<br/>
<br/>
<img src="http://www.habrastorage.com/images/ef6f3fc639.jpg" alt="PostgreSQL on tree"/><br/>
<br/>
Примеров можно привести множество. Это и древовидные комментарии, и каталог продукции, и населенные пункты, разделенные по странам и областям. Я думаю, что каждый сможет самостоятельно привести несколько примеров.<br/>
<br/>
В данном топике мы с вами поговорим об одной из тех возможностей, которые существуют для организации хранения деревьев в PostgreSQL — <b>ltree</b>.<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/postgresql/130371/#habracut">Читать дальше &rarr;</a> </div>]]></description>
		
		<pubDate>Fri, 14 Oct 2011 12:09:35 GMT</pubDate>
		<author>klestoff</author>
		<category>PostgreSQL</category><category>деревья бд</category><category>db tree</category><category>contrib</category><category>ltree</category>
	</item>
	
	
	
	
	
	

	
	
	
		
	<item>		
		<title><![CDATA[PostgreSQL / [Перевод] Зона недопонимания]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/postgresql/129319/</guid>
		<link>http://habrahabr.ru/blogs/postgresql/129319/</link>
		<description><![CDATA[<img src="http://habrastorage.org/storage1/99c693d3/0dfbe6c8/2e43b364/603c25da.jpg" align="right"/> По некоторым причинам, само понятие «времени с часовым поясом» сбивает с толку многих пользователей и разработчиков приложений. Это влечет за собой появление огромного числа шероховатостей в случае когда приложения должны иметь дело с множеством часовых поясов. В конечном итоге разработчики пытаются оформить эту логику в виде специального кода внутри приложения, в результате чего неизбежно получают заслуженный геморрой с обработкой данных.<br/>
<br/>
Вот некоторые распространенные ошибочные причины, которые я слышал, призывающие не использовать тип <i><a href="http://www.postgresql.org/docs/9.1/static/datatype-datetime.html">timestamp with time zone</a></i>:<br/>
<br/>
<ul>
<li> Я хочу хранить все в формате <a href="http://ru.wikipedia.org/wiki/UTC">UTC</a>;</li>
<li> Я не хочу получать несколько разных часовых поясов из запроса;</li>
<li> Мы используем специальную библиотеку для обработки часовых поясов;</li>
<li> Я не хочу тратить дисковое пространство для хранения часового пояса.</li>
</ul> <br/>
<br/>
Все эти тезисы произрастают из фундаментального непонимания принципов хранения временных данных в базе данных. <br/>
<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/postgresql/129319/#habracut">Читать дальше &rarr;</a> </div>]]></description>
		
		<pubDate>Wed, 28 Sep 2011 08:09:01 GMT</pubDate>
		<author>pasha_golub</author>
		<category>postgresql</category><category>timestamp</category><category>time zone</category><category>utc</category><category>часовой пояс</category>
	</item>
	
	
	

		
	<item>		
		<title><![CDATA[PostgreSQL / Выпущена PostgreSQL 9.1]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/postgresql/128293/</guid>
		<link>http://habrahabr.ru/blogs/postgresql/128293/</link>			
		<description><![CDATA[„Среди всех СУБД с открытым исходным кодом PostgreSQL 9.1 предоставляет несколько наиболее передовых промышленных возможностей и поддерживается энергичным и инновационным сообществом с показавшим себя успехом у потребителя. PostgreSQL — хорошо зарекомендовавшее себя решение для установки и запуска приложений в «облаке»,“ — заявил Чарльз Фан, старший вице-президент отдела исследования и разработок VMware.<br/>
<br/>
<b>Информация для пользователей</b><br/>
<br/>
Несколько функций, реализации которых пользователи просили годами, были добавлены в PostgreSQL 9.1, что позволяет избавиться от препятствий в развертывании новых или портированных приложений на PostgreSQL. В их числе:<br/>
<br/>
<ul>
<li>Синхронная репликация (Synchronous Replication): позволяет совместить высокую готовность со связностью на нескольких серверах.</li>
<li>Сравнение по колонке (Per-Column Collations): поддерживает лингвистически корректную сортировку в базе данных, таблице или колонке.</li>
<li>Беспротокольные таблицы (Unlogged Tables): значительное увеличение производительности работы с врéменными данными.</li>
</ul><br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/postgresql/128293/#habracut">Читать дальше &rarr;</a> </div>]]></description>
		
		<pubDate>Tue, 13 Sep 2011 03:07:42 GMT</pubDate>
		<author>FakeFactFelis</author>
		<category>postgresql</category><category>postgres</category><category>postgresql 9.1</category><category>от советского информбюро</category>
	</item>
	
	
	
	
	
	

	
		
	<item>		
		<title><![CDATA[PostgreSQL / [Из песочницы] Репликация базы данных PostgreSQL на основе SymmetricDS]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/postgresql/127282/</guid>
		<link>http://habrahabr.ru/blogs/postgresql/127282/</link>			
		<description><![CDATA[В этой статье я расскажу, как настроить репликацию баз данных для PostgreSQL. Для экспериментов будем использовать дистрибутив линукса CentOS 5.3, хотя это не принципиально. будем использовать версию PostgreSQL 8.4.7 и SymmetricDS-2.2.2.<br/>
<br/>
<h6>Что такое репликация? </h6><br/>
По сути, это механизм автоматической синхронизации содержимого баз данных, работающих на разных серверах. В результате репликации эти базы данных содержат абсолютно идентичные данные. Это нужно например для того, чтобы обеспечить отказоустойчивость системы (в случае падения первого сервера баз данных в работу вступает второй), или чтобы осуществить балансировку нагрузки — разных клиентов могут обслуживать разные сервера.<br/>
<br/>
Для репликации нужно как минимум два сервера баз данных, поэтому готовим два одинаковых сервера с базой данных PostgreSQL на каждом. У первого будет IP адрес 10.0.2.20, у второго — 10.0.2.21, у обоих гейтвей 10.0.2.2.<br/>
Можно обойтись виртуальной машиной, например VirtualBox, создать в ней два виртуальных сервера и запустить их на своем собственном компе.<br/>
<br/>
В приведенных командах первым символом будет стоять знак # либо $, эти знаки означают, что команда запускается из-под root или из-под обычного пользователя, соответственно.<br/>
Итак, какие действия нужно предпринять:<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/postgresql/127282/#habracut">Читать дальше &rarr;</a> </div>]]></description>
		
		<pubDate>Mon, 29 Aug 2011 13:46:41 GMT</pubDate>
		<author>danx</author>
		<category>PostgreSQL</category><category>replication</category><category>database</category>
	</item>
	
	
	
	
	

	
	
	
		
	<item>		
		<title><![CDATA[PostgreSQL / [Перевод] EnterpriseDB берет под опеку PostgreSQL на Itanium]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/postgresql/122797/</guid>
		<link>http://habrahabr.ru/blogs/postgresql/122797/</link>
		<description><![CDATA[Новость о <a href="http://www.opennet.ru/opennews/art.shtml?num=31091">выходе EnterpriseDB Postgre Plus Advanced Server 9.0</a>, главной особенностью которого стало добавление платформы HP-UX/Itanium, прошла как-то незаметно в рунете. Я решил восполнить этот пробел и перевести статью по этой теме, она, кстати, хорошо дополняет мои предыдущие посты:<br/>
 — <a href="http://habrahabr.ru/blogs/open_source/110417/">Как отразится противостояние HP и Oracle на Open Source?</a><br/>
 — <a href="http://habrahabr.ru/blogs/open_source/118239/"> Противостояние HP и Oracle. Продолжение. </a><br/>
<u>Внимание, перевод сокращён!</u> (Честно говоря, взялся переводить только из-за последнего абзаца, прочитайте его обязательно. ;-) <div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/postgresql/122797/#habracut">Читать дальше &rarr;</a> </div>]]></description>
		
		<pubDate>Wed, 20 Jul 2011 08:22:13 GMT</pubDate>
		<author>mister_fog</author>
		<category>postgresql</category><category>hp-ux</category><category>oracle database</category><category>enterprisedb</category><category>data bases</category><category>субд</category><category>itanium</category><category>hp</category>
	</item>
	
	
	

		
	<item>		
		<title><![CDATA[PostgreSQL / Минус на минус дает…]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/postgresql/120128/</guid>
		<link>http://habrahabr.ru/blogs/postgresql/120128/</link>			
		<description><![CDATA[<img align="left" src="http://static.trellis-club.com/uploads/pg_trollface.jpg" alt="image"/>Из школьного курса арифметики всем известно что минус на минус дает плюс. Ваш покорный слуга также всю свою жизнь был уверен в этой, казалось бы незыблемой, аксиоме. Но на днях, произошло событие, перевернувшее мировоззрение, и заставившее посмотреть новым взглядом на привычные вещи.<br/>
<br/>
В процессе разработки административных инструментов для <a href="http://trellis-club.com/ru/">клуба трельяж</a> понадобилась функция ануллирования всех результатов конкретной игры. Казалось бы, что может быть проще. Меняем статус игры, откатываем денормализационные данные со статистикой игроков, инвалидируем оперативные кеши, затрагивающие эти данные, и дело в шляпе. Но у связки PostgreSQL и psycopg2 на этот счет оказалось собственное мнение, не совпадающее с мнением редакции.<br/>
<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/postgresql/120128/#habracut">Читать дальше &rarr;</a> </div>]]></description>
		
		<pubDate>Fri, 27 May 2011 15:32:26 GMT</pubDate>
		<author>avl32</author>
		<category>PostgreSQL</category><category>sql</category><category>psycopg2</category><category>python</category><category>базы данных</category><category>программирование</category><category>трельяж</category>
	</item>
	
	
	
	
	
	

	
	
	
		
	<item>		
		<title><![CDATA[PostgreSQL / [Перевод] Миллиард таблиц?!]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/postgresql/120008/</guid>
		<link>http://habrahabr.ru/blogs/postgresql/120008/</link>
		<description><![CDATA[<img src="http://habrastorage.org/storage/66303030/ad3187ee/908aa78a/da1c10de.jpg" align="right"/> Благодаря презентации Селены Деккельман (<a href="http://www.chesnok.com/daily/">Selena Deckelmann</a>) на <a href="http://www.pgcon.org/2011/">pgCon</a>, некоторые из нас вовлеклись в дискуссию на тему «Сколько таблиц может теоретически потянуть PostgreSQL». На скорую руку был написан скрипт со смелой надеждой создать один миллиард таблиц следующего вида:<br/>
 <br/>
<pre><code class="sql">CREATE TABLE tab_### (
   id SERIAL NOT NULL PRIMARY KEY,
   value TEXT NOT NULL
);</code></pre><br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/postgresql/120008/#habracut">Узнай, удалось ли!</a> </div>]]></description>
		
		<pubDate>Thu, 26 May 2011 07:41:04 GMT</pubDate>
		<author>pasha_golub</author>
		<category>postgresql</category><category>sql</category><category>challenge</category>
	</item>
	
	
	

		
	<item>		
		<title><![CDATA[PostgreSQL / Книга «Работа с Postgresql: настройка, масштабирование», версия 2]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/postgresql/119279/</guid>
		<link>http://habrahabr.ru/blogs/postgresql/119279/</link>			
		<description><![CDATA[<img src="http://postgresql.leopard.in.ua/images/book.jpg" alt="image" align="left"/><br/>
<br/>
Я решил не затягивать выход обновления справочника и выпустил 2 версию «Работа с Postgresql: настройка, масштабирование».<br/>
<br/>
Как и раньше, в книге иследуются вопросы по настройке производительности Postgresql, репликации и кластеризации. <br/>
Добавил пару слов о расширениях PostgreSQL, методики решения проблем, сниплеты(пока в процессе). Произвел коррекцию ошибок в манах настроек. Пока что только сконвертирован pdf. Все правки и замечания прошу на этой странице <a href="https://github.com/le0pard/postgresql_book/issues">github.com/le0pard/postgresql_book/issues</a> или в комментариях.<br/>
<br/>
<b>Страница книги</b>: <a href="http://postgresql.leopard.in.ua/">postgresql.leopard.in.ua/</a><br/>
<b>Исходники</b>: <a href="https://github.com/le0pard/postgresql_book">github.com/le0pard/postgresql_book</a>]]></description>
		
		<pubDate>Sat, 14 May 2011 15:10:54 GMT</pubDate>
		<author>le0pard</author>
		<category>postgresql</category><category>книга на русском</category>
	</item>
	
	
	
	
	
	

	
	
	
		
	<item>		
		<title><![CDATA[PostgreSQL / [Перевод] Проект PSM (zero) завершен и нуждается в тебе]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/postgresql/117980/</guid>
		<link>http://habrahabr.ru/blogs/postgresql/117980/</link>
		<description><![CDATA[<img src="http://habrastorage.org/storage/9aa8be5f/a21fa8c9/57616f95/15e378cb.jpg" align="right"/>Вчера <a href="http://www.blogger.com/profile/01996484227228696817">Pavel Stehule</a> <a href="http://okbob.blogspot.com/2011/04/psm-zero-is-completed-and-needs-you.html">закончил</a> работу над реализацией процедурного языка <a href="http://ru.wikipedia.org/wiki/SQL/PSM">SQL/PSM</a> для PostgreSQL. <br/>
<br/>
На данный момент язык поддерживает всё необходимое:<br/>
<ul>
<li>простые вещи — массивы, составные типы (composites), триггеры;</li>
<li>дополнительные — функции, возвращающие таблицу, IN/OUT параметры;</li>
<li>особенности SQL/PSM — предупреждения, обработчики исключений (в большинстве на основе SQLCODE), операторы SIGNAL и RESIGNAL;</li>
<li>некоторые особенности DB2 и MySQL — multi assign операторы, поддержка магических переменных SQLSTATE и SQLCODE.</li>
</ul><br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/postgresql/117980/#habracut">Читать дальше &rarr;</a> </div>]]></description>
		
		<pubDate>Fri, 22 Apr 2011 11:43:30 GMT</pubDate>
		<author>pasha_golub</author>
		<category>postgresql</category><category>pl</category><category>sql</category><category>psm</category><category>pgsql</category>
	</item>
	
	
	

	
	
	
		
	<item>		
		<title><![CDATA[PostgreSQL / [Перевод] pg_log, pg_xlog, pg_clog: с чем их едят]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/postgresql/117813/</guid>
		<link>http://habrahabr.ru/blogs/postgresql/117813/</link>
		<description><![CDATA[<img src="http://habrastorage.org/storage/8ff50e33/c489c8e5/8209b6e9/824b8dc4.jpg" align="right"/> — Я тут типа удалил несколько Гб лог-файлов из каталога pg_xlog, чтобы освободить место на диске. Теперь моя база данных не взлетает.<br/>
<br/>
 — Ой-вей! Кхе-кхе… А когда говорите в последний раз резервную копию делали?<br/>
<br/>
Именно в такой форме несколько раз взывали заказчики и пользователи о помощи на нашем <a href="http://irc://irc.freenode.net/postgresql">IRC-канале</a>. Учитывая легкость повторения этой ошибки, я решил выложить некоторую информацию о системных каталогах <a href="http://www.postgresql.org/">PostgreSQL</a>.<br/>
<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/postgresql/117813/#habracut">Читать дальше &rarr;</a> </div>]]></description>
		
		<pubDate>Wed, 20 Apr 2011 08:34:46 GMT</pubDate>
		<author>pasha_golub</author>
		<category>postgresql</category><category>recovery</category><category>logs</category>
	</item>
	
	
	

	
	
	
		
	<item>		
		<title><![CDATA[PostgreSQL / [Перевод] Плохому танцору…]]></title>
		<guid isPermaLink="true">http://habrahabr.ru/blogs/postgresql/115264/</guid>
		<link>http://habrahabr.ru/blogs/postgresql/115264/</link>
		<description><![CDATA[Многие из вас <a href="http://habrahabr.ru/blogs/e_gov/114791/">читали</a> о последних эстонских выборах. И вот интересные факты.<br/>
<img src="http://habrastorage.org/storage/10be832e/ed825ba8/3e2f3b95/a1162081.gif" align="right"/><br/>
Эстонское правительство наняло IT-вендора Helmes для создания системы представления оперативных данных в течение последних эстонских парламентских выборов. Они (Helmes) построили совершенно новую систему, и по-видимому, не проверили ее в преддверии выборов. Неудивительно, что система упала, и статистика подавалась с задержкой на час.<br/>
<br/>
Почему я пишу об этом? Потому, что <a href="http://www.delfi.ee/news/rk/uudised/helmes-viga-oli-vabavaralises-andmebaasimootoris.d?id=41628665">Helmes обвиняет СУБД PostgreSQL</a> в задержке. Это все равно, что водитель после попадания в автомобильную аварию обвинит изготовителя двигателя, хотя сам мчался на красный свет. «Если бы только двигатель был чуточку мощнее», — жалуется Helmes, «мы бы проскочили этот чертов перекресток еще до того момента, как другие машины тронутся с места!»<br/>
<br/>
Предполагая, что Google Translate адекватен в своем переводе, Helmes предоставил поистине причудливое объяснение отсутствия тестирования:<br/>
<br/>
«Единственным способом предотвратить эту ситуацию была бы предварительная загрузка данных с тем же объемом информации, что и в разгар выборов. Это не нормально, так как запуск системы не должен зависеть от какого-либо объема псевдо-данных.»<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/postgresql/115264/#habracut">Читать дальше &rarr;</a> </div>]]></description>
		
		<pubDate>Fri, 11 Mar 2011 09:48:04 GMT</pubDate>
		<author>pasha_golub</author>
		<category>яйца мешают</category><category>postgresql</category><category>выборы</category><category>эстония</category>
	</item>
	
	
	

	

	
	
	
	
	
</channel>
</rss>

