Tom Lane escreveu: > The window for this sort of thing isn't very large, because the first > thing pg_dump does is acquire AccessShareLock on every table it intends > to dump, and past that point it won't be possible for anyone to modify > the table's DDL. But it can happen. > I did not see it documented anywhere. Should we at least add a comment at the top of pg_dump documenting this behavior? Attached is a proposed patch using your own words.
-- Euler Taveira de Oliveira http://www.timbira.com/
*** src/bin/pg_dump/pg_dump.c.orig 2010-02-19 23:22:56.000000000 -0200 --- src/bin/pg_dump/pg_dump.c 2010-02-19 23:43:08.000000000 -0200 *************** *** 11,16 **** --- 11,27 ---- * script that reproduces the schema in terms of SQL that is understood * by PostgreSQL * + * Note that pg_dump runs in a serializable transaction, so it sees a + * consistent snapshot of the database including system catalogs. + * However, it relies in part on various specialized backend functions + * like pg_get_indexdef(), and those things tend to run on SnapshotNow + * time, ie they look at the currently committed state. So it is + * possible to get 'cache lookup failed' error if someone performs DDL + * changes while a dump is happening. The window for this sort of thing + * is from the beginning of the serializable transaction to + * getSchemaData() (when pg_dump acquires AccessShareLock on every + * table it intends to dump). It isn't very large but it can happen. + * * IDENTIFICATION * $PostgreSQL$ *
-- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
