<?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; pitr</title>
	<atom:link href="http://www.depesz.com/tag/pitr/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.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; Unlogged tables</title>
		<link>http://www.depesz.com/2011/01/03/waiting-for-9-1-unlogged-tables/</link>
		<comments>http://www.depesz.com/2011/01/03/waiting-for-9-1-unlogged-tables/#comments</comments>
		<pubDate>Mon, 03 Jan 2011 13:07:01 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[performance]]></category>
		<category><![CDATA[pg91]]></category>
		<category><![CDATA[pitr]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[table]]></category>
		<category><![CDATA[unlogged]]></category>
		<category><![CDATA[wal]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1937</guid>
		<description><![CDATA[On 29th of December, Robert Haas committed interesting patch, which does: Support unlogged tables. &#160; The contents of an unlogged table aren't WAL-logged; thus, they are not available on standby servers and are truncated whenever the database system enters recovery. Indexes on unlogged tables are also unlogged. Unlogged GiST indexes are not currently supported. (edited [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2011/01/03/waiting-for-9-1-unlogged-tables/feed/</wfw:commentRss>
		<slash:comments>29</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; removal of 0000000001.history check</title>
		<link>http://www.depesz.com/2010/02/02/waiting-for-9-0-removal-of-0000000001-history-check/</link>
		<comments>http://www.depesz.com/2010/02/02/waiting-for-9-0-removal-of-0000000001-history-check/#comments</comments>
		<pubDate>Tue, 02 Feb 2010 14:35:21 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[pg85]]></category>
		<category><![CDATA[pg90]]></category>
		<category><![CDATA[pg_standby]]></category>
		<category><![CDATA[pitr]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[recovery]]></category>
		<category><![CDATA[restore]]></category>
		<category><![CDATA[restore_command]]></category>
		<category><![CDATA[standby]]></category>
		<category><![CDATA[wal]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1594</guid>
		<description><![CDATA[I tend to write about new features in new versions of PostgreSQL, but this patch actually fixes one of the things that annoy me a lot, so here it goes: On 26th of January, Simon Riggs committed: Log Message: ----------- Fix longstanding gripe that we check for 0000000001.history at start of archive recovery, even when [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2010/02/02/waiting-for-9-0-removal-of-0000000001-history-check/feed/</wfw:commentRss>
		<slash:comments>4</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>

