<?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; pg_dump</title>
	<atom:link href="http://www.depesz.com/tag/pg_dump/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.depesz.com</link>
	<description></description>
	<lastBuildDate>Tue, 07 Feb 2012 13:35:12 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>Waiting for 9.2 &#8211; excluding data of table from dump</title>
		<link>http://www.depesz.com/2011/12/15/waiting-for-9-2-excluding-data-of-table-from-dump/</link>
		<comments>http://www.depesz.com/2011/12/15/waiting-for-9-2-excluding-data-of-table-from-dump/#comments</comments>
		<pubDate>Thu, 15 Dec 2011 13:24:50 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[data]]></category>
		<category><![CDATA[exclude]]></category>
		<category><![CDATA[pg92]]></category>
		<category><![CDATA[pg_dump]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[table]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=2344</guid>
		<description><![CDATA[On 14h of December, Andrew Dunstan committed patch: Add --exclude-table-data option to pg_dump. &#160; Andrew Dunstan, reviewed by Josh Berkus, Robert Haas and Peter Geoghegan. &#160; This allows dumping of a table definition but not its data, on a per table basis. Table name patterns are supported just as for --exclude-table. This patch gives me [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2011/12/15/waiting-for-9-2-excluding-data-of-table-from-dump/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>Waiting for 9.1 &#8211; EXTENSIONS</title>
		<link>http://www.depesz.com/2011/03/02/waiting-for-9-1-extensions/</link>
		<comments>http://www.depesz.com/2011/03/02/waiting-for-9-1-extensions/#comments</comments>
		<pubDate>Wed, 02 Mar 2011 13:27:47 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[contrib]]></category>
		<category><![CDATA[dump]]></category>
		<category><![CDATA[extensions]]></category>
		<category><![CDATA[pg91]]></category>
		<category><![CDATA[pg_dump]]></category>
		<category><![CDATA[pg_restore]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[schema]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=2109</guid>
		<description><![CDATA[On 8th of February, Tom Lane committed patch: Core support for &#34;extensions&#34;, which are packages of SQL objects. &#160; This patch adds the server infrastructure to support extensions. There is still one significant loose end, namely how to make it play nice with pg_upgrade, so I am not yet committing the changes that would make [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2011/03/02/waiting-for-9-1-extensions/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Waiting for 9.0 &#8211; pg_upgrade</title>
		<link>http://www.depesz.com/2010/05/19/waiting-for-9-0-pg_upgrade/</link>
		<comments>http://www.depesz.com/2010/05/19/waiting-for-9-0-pg_upgrade/#comments</comments>
		<pubDate>Wed, 19 May 2010 10:55:02 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[pg85]]></category>
		<category><![CDATA[pg90]]></category>
		<category><![CDATA[pg_dump]]></category>
		<category><![CDATA[pg_restore]]></category>
		<category><![CDATA[pg_upgrade]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[upgrade]]></category>
		<category><![CDATA[version]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1700</guid>
		<description><![CDATA[On May, 12ve, Bruce Momjian committed new contrib module for 9.0 &#8211; pg_upgrage. As I understand &#8211; this is what was available before as pg-migrator. If you&#8217;re not familiar with it &#8211; it&#8217;s a tool that allows upgrade of $PGDATA from some version to some version. What&#8217;s the use case? Let&#8217;s assume you have this [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2010/05/19/waiting-for-9-0-pg_upgrade/feed/</wfw:commentRss>
		<slash:comments>7</slash:comments>
		</item>
		<item>
		<title>Speeding up dump/restore process</title>
		<link>http://www.depesz.com/2009/09/19/speeding-up-dumprestore-process/</link>
		<comments>http://www.depesz.com/2009/09/19/speeding-up-dumprestore-process/#comments</comments>
		<pubDate>Sat, 19 Sep 2009 17:27:53 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[dump]]></category>
		<category><![CDATA[pg_dump]]></category>
		<category><![CDATA[pg_restore]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[rsync]]></category>
		<category><![CDATA[usecase]]></category>
		<category><![CDATA[xargs]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1502</guid>
		<description><![CDATA[As some of you know, I&#8217;ve been working lately for OmniTI company. When doing things for them (PostgreSQL related of course , I stumbled on very interesting problem. One of our clients is working on PostgreSQL 8.2, and wants to upgrade to 8.3. This is generally trivial &#8211; pg_dump, pg_restore/psql, and you&#8217;re done. But, this [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2009/09/19/speeding-up-dumprestore-process/feed/</wfw:commentRss>
		<slash:comments>27</slash:comments>
		</item>
		<item>
		<title>Waiting for 8.4 &#8211; no more -d in pg_dump!</title>
		<link>http://www.depesz.com/2009/03/22/waiting-for-84-no-more-d-in-pg_dump/</link>
		<comments>http://www.depesz.com/2009/03/22/waiting-for-84-no-more-d-in-pg_dump/#comments</comments>
		<pubDate>Sun, 22 Mar 2009 19:06:58 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[pg84]]></category>
		<category><![CDATA[pg_dump]]></category>
		<category><![CDATA[pg_dumpall]]></category>
		<category><![CDATA[postgresql]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1394</guid>
		<description><![CDATA[Usually I write about new features in 8.4, but this time I&#8217;d like to write about feature that will be actually missing in 8.4. And thank God, it will be missing. On Mon, 09 Mar 2009 11:22:47 -0400 Greg Sabino Mullane wrote mail to pgsql-hackers list with his patch that removes -d switch from pg_dump. [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2009/03/22/waiting-for-84-no-more-d-in-pg_dump/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Waiting for 8.4 &#8211; parallel restoration of dumps</title>
		<link>http://www.depesz.com/2009/02/09/waiting-for-84-parallel-restoration-of-dumps/</link>
		<comments>http://www.depesz.com/2009/02/09/waiting-for-84-parallel-restoration-of-dumps/#comments</comments>
		<pubDate>Mon, 09 Feb 2009 12:27:46 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[backup]]></category>
		<category><![CDATA[parallel]]></category>
		<category><![CDATA[pg84]]></category>
		<category><![CDATA[pg_dump]]></category>
		<category><![CDATA[pg_restore]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[restore]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1377</guid>
		<description><![CDATA[On 2nd of February Andrew Dunstan committed his patch (with editing by Tom Lane) that: Log Message: ----------- Provide for parallel restoration from a custom format archive. Each data and post-data step is run in a separate worker child (a thread on Windows, a child process elsewhere) up to the concurrent number specified by the [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2009/02/09/waiting-for-84-parallel-restoration-of-dumps/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>Waiting for 8.4 &#8211; ordered data loading in pg_dump</title>
		<link>http://www.depesz.com/2008/09/08/waiting-for-84-ordered-data-loading-in-pg_dump/</link>
		<comments>http://www.depesz.com/2008/09/08/waiting-for-84-ordered-data-loading-in-pg_dump/#comments</comments>
		<pubDate>Mon, 08 Sep 2008 18:55:45 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[pg84]]></category>
		<category><![CDATA[pg_dump]]></category>
		<category><![CDATA[postgresql]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1255</guid>
		<description><![CDATA[Great (and admittedly long overdue) patch by Tom Lane: Make pg_dump --data-only try to order the table dumps so that foreign keys' referenced tables are dumped before the referencing tables. This avoids failures when the data is loaded with the FK constraints already active. If no such ordering is possible because of circular or self-referential [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2008/09/08/waiting-for-84-ordered-data-loading-in-pg_dump/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
	</channel>
</rss>

