Re: Potential bug in pg_dump ... - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Potential bug in pg_dump ...
Date
Msg-id 3459.1010791811@sss.pgh.pa.us
Whole thread Raw
In response to Re: Potential bug in pg_dump ...  (Brent Verner <brent@rcfile.org>)
Responses Re: Potential bug in pg_dump ...  (Brent Verner <brent@rcfile.org>)
List pgsql-hackers
Brent Verner <brent@rcfile.org> writes:
> Attached is a patch that implements table locking for pg_dump.

Checked and applied, with some small tweaking.  I broke the outer loop
of getTables() into two loops, one that extracts data from the pg_class
SELECT result and locks the target tables, and a second one that does
the rest of the stuff that that routine does.  This is to minimize the
time window between doing the pg_class SELECT and locking the tables.

In testing this thing, I noticed that pg_dump spends a really
unreasonable amount of time on schema extraction.  For example, on the
regression database the actual COPY commands take less than a quarter of
the runtime.  (Of course, regression deliberately doesn't contain huge
volumes of data, so this case may be unrepresentative of real-world
situations.)  The retail queries to get table attributes, descriptions,
etc are probably the cause.  Something to think about improving
someday...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Don Baccus
Date:
Subject: Re: again on index usage
Next
From: Brent Verner
Date:
Subject: Re: Potential bug in pg_dump ...