Re: Potential bug in pg_dump ...
| От | Tom Lane |
|---|---|
| Тема | Re: Potential bug in pg_dump ... |
| Дата | |
| Msg-id | 3459.1010791811@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Potential bug in pg_dump ... (Brent Verner <brent@rcfile.org>) |
| Ответы |
Re: Potential bug in pg_dump ...
|
| Список | 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 по дате отправления: