-----BEGIN PGP SIGNED MESSAGE-----
On 03/17/2014 05:55 PM, Jeff Janes wrote:
> On Mon, Mar 17, 2014 at 5:48 PM, Craig Ringer
> <cr...@2ndquadrant.com I wonder if doing large batches of
> 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.
Not surprising at all. The huge time is incurred in taking the locks,
but if you are trying to use pg_upgrade in link mode to speed your
upgrade, you are totally hosed by the time it takes to grab those locks.
This patch applied to 9.3 substantially fixes the issue:
Author: Heikki Linnakangas <heikki.linnakan...@iki.fi>
Date: Thu Jun 21 15:01:17 2012 +0300
Add a small cache of locks owned by a resource owner in ResourceOwner.
On my 8.4 database, with 500,000 tables there were about 2.5 million
locks taken including toast tables and indexes during the schema dump.
Without the patch grabbing locks took many, many days with that many
objects to lock. With a backported version of the patch, one hour.
So if you have a problem due to many tables on an older than 9.3
version of Postgres, this is the direction to head (a custom patch
applied to your old version just long enough to get successfully
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7 Support
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: