From: | Jim Nasby <jim(at)nasby(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Jürgen Strobel <juergen+pg(at)strobel(dot)info>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_dump without explicit table locking |
Date: | 2014-03-17 22:51:03 |
Message-ID: | 53277C57.4040404@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 3/17/14, 8:47 AM, Tom Lane wrote:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>> 2014-03-17 12:52 GMT+01:00 Jürgen Strobel <juergen+pg(at)strobel(dot)info>:
>>> I've googled the problem and there seem to be more people with similar
>>> problems, so I made this a command line option --no-table-locks and
>>> wrapped it up in as nice a patch against github/master as I can manage
>>> (and I didn't use C for a long time). I hope you find it useful.
>
>> Joe Conway sent me a tip so commit eeb6f37d89fc60c6449ca12ef9e914
>> 91069369cb significantly decrease a time necessary for locking. So it can
>> help to.
>
> Indeed. I think there's zero chance that we'd accept the patch as
> proposed. If there's still a performance problem in HEAD, we'd look
> for some other way to improve matters more.
>
> (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.
--
Jim C. Nasby, Data Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2014-03-17 23:12:12 | Re: BUG #9555: pg_dump for tables with inheritance recreates the table with the wrong order of columns |
Previous Message | Noah Misch | 2014-03-17 22:48:20 | Re: AUTOCOMMIT off + ON_ERROR_ROLLBACK usability |