From: | Jerry Sievers <gsievers19(at)comcast(dot)net> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Ray Stell <stellr(at)vt(dot)edu>, "pgsql-admin\(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: 9.4 pg_dump use on 9.0 db |
Date: | 2015-01-13 18:06:16 |
Message-ID: | 86a91m5zdz.fsf@jerry.enova.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Stephen Frost (sfrost(at)snowman(dot)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(dot)consulting(at)comcast(dot)net
p: 312.241.7800
From | Date | Subject | |
---|---|---|---|
Next Message | Campbell, Lance | 2015-01-14 15:56:40 | How to identify all storage in a schema |
Previous Message | Stephen Frost | 2015-01-13 15:36:10 | Re: 9.4 pg_dump use on 9.0 db |