Re: Potential bug in pg_dump ...

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Potential bug in pg_dump ...
Дата
Msg-id 7593.1008626811@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Potential bug in pg_dump ...  (Philip Warner <pjw@rhyme.com.au>)
Ответы Re: Potential bug in pg_dump ...  (Brent Verner <brent@rcfile.org>)
Список pgsql-hackers
Philip Warner <pjw@rhyme.com.au> writes:
> At 14:10 17/12/01 -0500, Marc G. Fournier wrote:
>> Got a report the other day of a "problem" with pg_dump where, if in the
>> middle of a dump, someone happens to drop a table, it errors out with:

> pg_dump runs in a single TX, which should mean that metadata changes in
> another process won't affect it. Have I misunderstood the way PG handles
> metadata changes?

In the case Marc is describing, pg_dump hasn't yet tried to touch the
table that someone else is dropping, so it has no lock on the table,
so the drop is allowed to occur.

A possible (partial) solution is for pg_dump to obtain a read-lock on
every table in the database as soon as it sees the table mentioned in
pg_class, rather than waiting till it's ready to read the contents of
the table.  However this cure might be worse than the disease,
particularly for people running "pg_dump -t table".
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Philip Warner
Дата:
Сообщение: Re: Potential bug in pg_dump ...
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Explicit config patch 7.2B4, not "-C" ??