Re: pg_dump without explicit table locking
От | Jeff Janes |
---|---|
Тема | Re: pg_dump without explicit table locking |
Дата | |
Msg-id | CAMkU=1xox5YcFOh5P_hNzxcNeVpGTu8N3ii6hfqGCdTFB5wBSA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_dump without explicit table locking (Craig Ringer <craig@2ndquadrant.com>) |
Ответы |
Re: pg_dump without explicit table locking
|
Список | pgsql-hackers |
On Mon, Mar 17, 2014 at 5:48 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1On 03/18/2014 07:20 AM, Joe Conway wrote:I wonder if doing large batches of
> On 03/17/2014 04:15 PM, Tom Lane wrote:
>> Jim Nasby <jim@nasby.net> writes:
>>> On 3/17/14, 8:47 AM, Tom Lane wrote:
>>>> (Note that this is only one of assorted O(N^2) behaviors in
>>>> older versions of pg_dump; we've gradually stamped them out
>>>> over time.)
>
>>> On that note, it's recommended that when you are taking a
>>> backup to restore into a newer version of Postgres you create
>>> the dump using the NEWER version of pg_dump, not the old one.
>
>> Right. IIRC, the OP said he *did* use a recent pg_dump ... but
>> this particular issue got fixed server-side, so the new pg_dump
>> didn't help against an 8.1 server :-(
>
> Exactly. I backported the patch from 9.3 to 8.4 and saw a
> schema-only dump time go from <give-up-and-kill-it-after-5-days> to
> 1 hour. This was for a database with about 500k tables.
LOCK TABLE table1, table2, table3, ...
would help, instead of doing individual statements?
If I recall correctly, someone did submit a patch to do that. It helped when dumping schema only, but not much when dumping data.
Cheers,
Jeff
В списке pgsql-hackers по дате отправления: