Re: BUG #6167: pg_dump fails on table lock

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #6167: pg_dump fails on table lock
Дата
Msg-id 3308.1313697597@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #6167: pg_dump fails on table lock  (Jesper Engman <jesper@engman.net>)
Список pgsql-bugs
Jesper Engman <jesper@engman.net> writes:
> I wonder if there is a small time span between when pg_dump starts and
> when all locks have been acquired that may be the problem (if a table
> is dropped during that time span). Is there such a small time of
> vulnerability?

Certainly.  pg_dump has to read pg_class to get the names of the tables,
and then try to lock each one.  If you drop a table during that window,
the lock command will fail.

The window is actually a bit longer than necessary in existing releases,
because pg_dump was doing some other stuff before it got around to
acquiring the locks.  I fixed that recently
http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=68d977a73
but that patch hasn't made it to any released versions yet.  In any case
there's still a nonzero window.

> Excluding tables from the dump is not an option - that will be an
> incomplete backup.

Um ... if you know it's a transient table, why do you care about backing
it up?

            regards, tom lane

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

Предыдущее
От: Jesper Engman
Дата:
Сообщение: Re: BUG #6167: pg_dump fails on table lock
Следующее
От: "Marc Mamin"
Дата:
Сообщение: BUG #6168: db_link may generate additional unformatted log entries in stderr