Re: Potential bug in pg_dump ...

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Brent Verner <brent(at)rcfile(dot)org>
Cc: Philip Warner <pjw(at)rhyme(dot)com(dot)au>, "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Potential bug in pg_dump ...
Date: 2002-01-11 23:30:11
Message-ID: 3459.1010791811@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Brent Verner <brent(at)rcfile(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Brent Verner 2002-01-12 02:10:04 Re: Potential bug in pg_dump ...
Previous Message Don Baccus 2002-01-11 19:42:38 Re: again on index usage