<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>select * from depesz; &#187; replication</title>
	<atom:link href="http://www.depesz.com/tag/replication/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.depesz.com</link>
	<description></description>
	<lastBuildDate>Mon, 07 May 2012 20:34:27 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
		<item>
		<title>OmniPITR 0.7.0</title>
		<link>http://www.depesz.com/2012/05/07/omnipitr-0-7-0/</link>
		<comments>http://www.depesz.com/2012/05/07/omnipitr-0-7-0/#comments</comments>
		<pubDate>Mon, 07 May 2012 20:34:27 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[announcements]]></category>
		<category><![CDATA[backups]]></category>
		<category><![CDATA[omnipitr]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[replication]]></category>
		<category><![CDATA[wal]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=2451</guid>
		<description><![CDATA[Just released new version of OmniPITR. This version has one important new feature: when you&#8217;re calling omnipitr-backup-slave, it will make backups only of required xlog files, and not, as previously, of all in walarchive directory. This is important, especially in case you have multiple slaves, or you keep shared long-term walarchive. Previously &#8211; backups would [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2012/05/07/omnipitr-0-7-0/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>OmniPITR 0.6.0</title>
		<link>http://www.depesz.com/2012/04/26/omnipitr-0-6-0/</link>
		<comments>http://www.depesz.com/2012/04/26/omnipitr-0-6-0/#comments</comments>
		<pubDate>Thu, 26 Apr 2012 20:21:09 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[announcements]]></category>
		<category><![CDATA[omnipitr]]></category>
		<category><![CDATA[pitr]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[replication]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=2448</guid>
		<description><![CDATA[Just released new version, 0.6.0 (it should be visible on pgxn soon) of OmniPITR set of tools. New version has one new feature &#8211; parallelism. This works in omnipitr-archive and omnipitr-backup-* programs, and allows for parallel delivery to remote destinations (multiple -dr switches). Also &#8211; if you&#8217;re using compresses wal archive and omnipitr-backup-slave reading from [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2012/04/26/omnipitr-0-6-0/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>OmniPITR 0.5.0</title>
		<link>http://www.depesz.com/2012/03/30/omnipitr-0-5-0/</link>
		<comments>http://www.depesz.com/2012/03/30/omnipitr-0-5-0/#comments</comments>
		<pubDate>Fri, 30 Mar 2012 10:10:31 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[backups]]></category>
		<category><![CDATA[bash]]></category>
		<category><![CDATA[justintv]]></category>
		<category><![CDATA[omnipitr]]></category>
		<category><![CDATA[omniti]]></category>
		<category><![CDATA[perl]]></category>
		<category><![CDATA[pipes]]></category>
		<category><![CDATA[pitr]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[replication]]></category>
		<category><![CDATA[ssh]]></category>
		<category><![CDATA[wal]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=2424</guid>
		<description><![CDATA[Today, I released new version of OmniPITR &#8211; 0.5.0. This new version has one important new feature &#8211; which is so called &#8220;direct destination&#8221; for backups. What it means? What it does? How it helps? Let&#8217;s see&#8230; Let&#8217;s assume you have remote destination for backups, something like: $ omnipitr-backup-master ... -dr gzip=storage.host:/path/to/store/backups ... Up to [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2012/03/30/omnipitr-0-5-0/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Waiting for 9.2 &#8211; pg_basebackup from slave</title>
		<link>http://www.depesz.com/2012/02/03/waiting-for-9-2-pg_basebackup-from-slave/</link>
		<comments>http://www.depesz.com/2012/02/03/waiting-for-9-2-pg_basebackup-from-slave/#comments</comments>
		<pubDate>Fri, 03 Feb 2012 14:08:48 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[omnipitr]]></category>
		<category><![CDATA[pg92]]></category>
		<category><![CDATA[pg_basebackup]]></category>
		<category><![CDATA[pitr]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[replication]]></category>
		<category><![CDATA[slave]]></category>
		<category><![CDATA[wal]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=2399</guid>
		<description><![CDATA[On 25th of January, Simon Riggs committed patch: Allow pg_basebackup from standby node with safety checking. Base backup follows recommended procedure, plus goes to great lengths to ensure that partial page writes are avoided. &#160; Jun Ishizuka and Fujii Masao, with minor modifications In PostgreSQL 9.1 we got pg_basebackup &#8211; it is a tool to [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2012/02/03/waiting-for-9-2-pg_basebackup-from-slave/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>OmniPITR 0.3.0</title>
		<link>http://www.depesz.com/2012/01/04/omnipitr-0-3-0/</link>
		<comments>http://www.depesz.com/2012/01/04/omnipitr-0-3-0/#comments</comments>
		<pubDate>Wed, 04 Jan 2012 20:44:42 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[announcements]]></category>
		<category><![CDATA[omnipitr]]></category>
		<category><![CDATA[omniti]]></category>
		<category><![CDATA[perl]]></category>
		<category><![CDATA[pitr]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[replication]]></category>
		<category><![CDATA[wal]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=2355</guid>
		<description><![CDATA[Just released version 0.3.0 of our tool for handling WAL based replication in PostgreSQL &#8211; OmniPITR. Version jump is related to addition of another tool &#8211; omnipitr-synch. This tool is used to copy PostgreSQL data dir (including all tablespaces of course) to remote location(s). While this process is usually simple (call pg_start_backup(), transfer data, call [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2012/01/04/omnipitr-0-3-0/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Waiting for 9.2 &#8211; cascading streaming replication</title>
		<link>http://www.depesz.com/2011/07/26/waiting-for-9-2-cascading-streaming-replication/</link>
		<comments>http://www.depesz.com/2011/07/26/waiting-for-9-2-cascading-streaming-replication/#comments</comments>
		<pubDate>Tue, 26 Jul 2011 11:30:14 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[cascade]]></category>
		<category><![CDATA[pg92]]></category>
		<category><![CDATA[pitr]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[replication]]></category>
		<category><![CDATA[slave]]></category>
		<category><![CDATA[streaming]]></category>
		<category><![CDATA[wal]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=2268</guid>
		<description><![CDATA[On 19th of July, Simon Riggs committed patch: Cascading replication feature FOR streaming log-based replication. Standby servers can now have WALSender processes, which can WORK WITH either WALReceiver OR archive_commands TO pass DATA. Fully updated docs, including NEW conceptual terms OF sending server, upstream AND downstream servers. WALSenders TERMINATED WHEN promote TO master. &#160; Fujii [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2011/07/26/waiting-for-9-2-cascading-streaming-replication/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Waiting for 9.1 &#8211; Synchronous replication</title>
		<link>http://www.depesz.com/2011/03/18/waiting-for-9-1-synchronous-replication/</link>
		<comments>http://www.depesz.com/2011/03/18/waiting-for-9-1-synchronous-replication/#comments</comments>
		<pubDate>Fri, 18 Mar 2011 13:12:58 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[pg91]]></category>
		<category><![CDATA[pg_stat_replication]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[replication]]></category>
		<category><![CDATA[sr]]></category>
		<category><![CDATA[streaming]]></category>
		<category><![CDATA[sync]]></category>
		<category><![CDATA[synchronous]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=2140</guid>
		<description><![CDATA[On 6th of March, Simon Riggs committed patch: Efficient transaction-controlled synchronous replication. If a standby is broadcasting reply messages and we have named one or more standbys in synchronous_standby_names then allow users who set synchronous_replication to wait for commit, which then provides strict data integrity guarantees. Design avoids sending and receiving transaction state information so [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2011/03/18/waiting-for-9-1-synchronous-replication/feed/</wfw:commentRss>
		<slash:comments>26</slash:comments>
		</item>
		<item>
		<title>Waiting for 9.1 &#8211; pg_ctl promote</title>
		<link>http://www.depesz.com/2011/03/05/waiting-for-9-1-pg_ctl-promote/</link>
		<comments>http://www.depesz.com/2011/03/05/waiting-for-9-1-pg_ctl-promote/#comments</comments>
		<pubDate>Sat, 05 Mar 2011 13:32:33 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[pg91]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[promote]]></category>
		<category><![CDATA[replication]]></category>
		<category><![CDATA[standby]]></category>
		<category><![CDATA[streaming]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=2117</guid>
		<description><![CDATA[On 16th of February, , Robert Haas committed patch: pg_ctl promote &#160; Fujii Masao, reviewed by Robert Haas, Stephen Frost, and Magnus Hagander. Commit log is very short, functionality is not really new, but the important thing is that we&#8217;re getting support for PostgreSQL replication in more &#8220;administrative&#8221; places, which makes the whole process more [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2011/03/05/waiting-for-9-1-pg_ctl-promote/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>OmniPITR &#8211; update</title>
		<link>http://www.depesz.com/2011/02/11/omnipitr-update-2/</link>
		<comments>http://www.depesz.com/2011/02/11/omnipitr-update-2/#comments</comments>
		<pubDate>Fri, 11 Feb 2011 09:21:07 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[backup]]></category>
		<category><![CDATA[omnipitr]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[recovery]]></category>
		<category><![CDATA[replication]]></category>
		<category><![CDATA[streaming]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=2098</guid>
		<description><![CDATA[As of yesterday OmniPITR got following changes/fixes: Fixed bug which caused immediate finish request be treated the same as smart finish request. Fixed problem with using omnipitr-backup-slave on PostgreSQL 9.0 slave, which is using streaming replication. Added option to omnipitr-restore, so that you can now use it for streaming-replication slaves I&#8217;m very ashamed of the [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2011/02/11/omnipitr-update-2/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Waiting for 9.1 &#8211; pg_basebackup</title>
		<link>http://www.depesz.com/2011/01/24/waiting-for-9-1-pg_basebackup/</link>
		<comments>http://www.depesz.com/2011/01/24/waiting-for-9-1-pg_basebackup/#comments</comments>
		<pubDate>Mon, 24 Jan 2011 14:39:16 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[backup]]></category>
		<category><![CDATA[pg91]]></category>
		<category><![CDATA[pg_basebackup]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[replication]]></category>
		<category><![CDATA[streaming]]></category>
		<category><![CDATA[walsender]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=2093</guid>
		<description><![CDATA[On 23rd of January, Magnus Hagander committed patch which adds: Add pg_basebackup tool for streaming base backups &#160; This tool makes it possible to do the pg_start_backup/ copy files/pg_stop_backup step in a single command. &#160; There are still some steps to be done before this is a complete backup solution, such as the ability to [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2011/01/24/waiting-for-9-1-pg_basebackup/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>Waiting for 9.1 &#8211; pg_stat_replication</title>
		<link>http://www.depesz.com/2011/01/24/waiting-for-9-1-pg_stat_replication/</link>
		<comments>http://www.depesz.com/2011/01/24/waiting-for-9-1-pg_stat_replication/#comments</comments>
		<pubDate>Mon, 24 Jan 2011 14:06:31 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[pg91]]></category>
		<category><![CDATA[pg_basebackup]]></category>
		<category><![CDATA[pg_stat_replication]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[replication]]></category>
		<category><![CDATA[streaming]]></category>
		<category><![CDATA[walsender]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=2089</guid>
		<description><![CDATA[On 7th of January (I know, it was quite some time ago, I apologize for delay) Itagaki Takahiro committed patch: New system view pg_stat_replication displays activity of wal sender processes. &#160; Itagaki Takahiro and Simon Riggs. This view is very simple, but it shows all necessary information. For example, in my simple test case with [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2011/01/24/waiting-for-9-1-pg_stat_replication/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>OmniPITR &#8211; hot backup on slave</title>
		<link>http://www.depesz.com/2010/08/18/omnipitr-hot-backup-on-slave/</link>
		<comments>http://www.depesz.com/2010/08/18/omnipitr-hot-backup-on-slave/#comments</comments>
		<pubDate>Wed, 18 Aug 2010 12:36:52 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[backup]]></category>
		<category><![CDATA[omnipitr]]></category>
		<category><![CDATA[pitr]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[replication]]></category>
		<category><![CDATA[slave]]></category>
		<category><![CDATA[wal]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1810</guid>
		<description><![CDATA[Well, the biggest information is that hot-backups on slave work. And they work fine. Really fine. Some more information (with nice graph!): Background: hot backup is backup of database server, done with backing up data files, and not issuing pg_dump. There are certain benefits of doing it &#8211; for example the fact that if you&#8217;d [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2010/08/18/omnipitr-hot-backup-on-slave/feed/</wfw:commentRss>
		<slash:comments>7</slash:comments>
		</item>
		<item>
		<title>Setting WAL Replication</title>
		<link>http://www.depesz.com/2010/03/11/setting-wal-replication/</link>
		<comments>http://www.depesz.com/2010/03/11/setting-wal-replication/#comments</comments>
		<pubDate>Thu, 11 Mar 2010 12:57:25 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[failover]]></category>
		<category><![CDATA[pg_standby]]></category>
		<category><![CDATA[pitr]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[replication]]></category>
		<category><![CDATA[standby]]></category>
		<category><![CDATA[wal]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1640</guid>
		<description><![CDATA[There are several approaches on replication/failover &#8211; you might have heard of Slony, Londiste, pgPool and some other tools. WAL Replication is different from all of them in one aspect &#8211; it doesn&#8217;t let you query slave database (until 9.0, in which you actually can run read only queries on slave. Since you can&#8217;t run [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2010/03/11/setting-wal-replication/feed/</wfw:commentRss>
		<slash:comments>14</slash:comments>
		</item>
		<item>
		<title>Waiting for 9.0 &#8211; Streaming replication</title>
		<link>http://www.depesz.com/2010/02/01/waiting-for-9-0-streaming-replication/</link>
		<comments>http://www.depesz.com/2010/02/01/waiting-for-9-0-streaming-replication/#comments</comments>
		<pubDate>Sun, 31 Jan 2010 23:49:31 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[hot standby]]></category>
		<category><![CDATA[pg85]]></category>
		<category><![CDATA[pg90]]></category>
		<category><![CDATA[pitr]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[replication]]></category>
		<category><![CDATA[standby]]></category>
		<category><![CDATA[streaming]]></category>
		<category><![CDATA[wal]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1586</guid>
		<description><![CDATA[The BIG feature. The feature that made PostgreSQL leap from 8.4 to 9.0. Patch was written by Fujii Masao, and committed by Heikki Linnakangas on 15th of January 2010: Log Message: ----------- Introduce Streaming Replication. &#160; This includes two new kinds of postmaster processes, walsenders and walreceiver. Walreceiver is responsible for connecting to the primary [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2010/02/01/waiting-for-9-0-streaming-replication/feed/</wfw:commentRss>
		<slash:comments>15</slash:comments>
		</item>
		<item>
		<title>Waiting for 8.5 &#8211; Hot Standby</title>
		<link>http://www.depesz.com/2010/01/08/waiting-for-8-5-hot-standby/</link>
		<comments>http://www.depesz.com/2010/01/08/waiting-for-8-5-hot-standby/#comments</comments>
		<pubDate>Fri, 08 Jan 2010 15:07:27 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[availability]]></category>
		<category><![CDATA[hot standby]]></category>
		<category><![CDATA[pg85]]></category>
		<category><![CDATA[pg90]]></category>
		<category><![CDATA[pitr]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[replication]]></category>
		<category><![CDATA[slony]]></category>
		<category><![CDATA[wal]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1576</guid>
		<description><![CDATA[On 19th of December Simon Riggs committed a patch that will quite likely be the single most-talked-about change in PostgreSQL 8.5: Log Message: ----------- Allow read only connections during recovery, known as Hot Standby. &#160; Enabled by recovery_connections = on (default) and forcing archive recovery using a recovery.conf. Recovery processing now emulates the original transactions [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2010/01/08/waiting-for-8-5-hot-standby/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
	</channel>
</rss>

