From: Jerry Sievers <gsievers19@comcast.net>
To: Stephen Frost <sfrost@snowman.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Ray Stell <stellr@vt.edu>,
 "pgsql-admin\@postgresql.org" <pgsql-admin@postgresql.org>
Subject: Re: 9.4 pg_dump use on 9.0 db
References: <54B52E9B.8020208@vt.edu> <11235.1421162639@sss.pgh.pa.us>
 <20150113153445.GQ3062@tamriel.snowman.net>
 <20150113153610.GR3062@tamriel.snowman.net>
Date: Tue, 13 Jan 2015 12:06:16 -0600
In-Reply-To: <20150113153610.GR3062@tamriel.snowman.net> (Stephen Frost's
 message of "Tue, 13 Jan 2015 10:36:10 -0500")
Message-ID: <86a91m5zdz.fsf@jerry.enova.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org

Stephen Frost <sfrost@snowman.net> writes:

> * Stephen Frost (sfrost@snowman.net) wrote:
>
>> Looking at pg_dump, for my 2c anyway, it'd be nicer if we threw an error
>> on parallel dump request when the major version doesn't support
>> synchronized snapshots, unless the user explicitly passed
>> --no-synchronized-snapshots, indicating that they don't care.
>
> Ah, bah, we do that already.  Good on us.  I was looking at where the
> snapshot is actually taken and didn't notice the earlier check.

The OP didn't mention if the DB is huge and/or inconvenient to quiesce.

But in any case, doing a --jobs N dump from a per-snapshot origin system
requuires the system be quiescent just long enough to get the pg_dump
master process and all workers connected.

I assume this is due to pg_dump running all of its N workers each using
a persistent connection and in a serialized transaction.

Thus --jobs --no-sync-snap is very slick indeedy!!

FYI

>
> Nevermind me.
>
> 	Thanks,
>
> 		Stephen

-- 
Jerry Sievers
Postgres DBA/Development Consulting
e: postgres.consulting@comcast.net
p: 312.241.7800


-- 
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin