Re: pg_dump without explicit table locking

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: 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 13:47:43
Message-ID: 6388.1395064063@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> 2014-03-17 12:52 GMT+01:00 Jrgen 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.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2014-03-17 13:59:09 Re: Archive recovery won't be completed on some situation.
Previous Message Alvaro Herrera 2014-03-17 13:44:56 Re: HEAD seems to generate larger WAL regarding GIN index