[2001-12-17 17:06] Tom Lane said:
| 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".
How would this lock-when-seen approach cause problems with '-t'?
ISTM, that we could make getTables like
tblinfo = getTables(&numTables, finfo, numFuncs, tablename);
so only that table gets locked when reading pg_class if tablename
isn't NULL, otherwise all tables get locked.
Aside from me not being familiar with the specifics of table locking,
avoiding the "table dropped during dump" condition looks
straightforward and uncomplicated. From reading the docs, an
ACCESS SHARE lock should keep any pending ALTER TABLE from modifying
the table.
What am I overlooking?
b
--
"Develop your talent, man, and leave the world something. Records are
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing." -- Duane Allman
