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 по дате отправления: