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$
*
