Alvaro Herrera <alvhe...@2ndquadrant.com> writes:
> One concern is schema changes that make a dump unrestorable, for
> instance if there's a foreign key relationship between tables A and B,
Yeah. Ideally, what pg_dump would produce would be a consistent snapshot
of the database state as of its transaction snapshot time. We have always
had that guarantee so far as user data was concerned, but it's been shaky
(and getting worse) so far as the database schema is concerned. What
bothers me about the current patch is that it's going to make it a whole
lot more worse.
Also, I don't have any love at all for proposals that we increase the lock
level that pg_dump holds. pg_dump tends to run for a long time.
I've not been paying all that much attention to the logical-decoding
patches, but wasn't there something in there about being able to see
the catalog state as it was at some point in the past? If so, maybe
we could leverage that to allow a backend to enter a "pg_dump state"
wherein its view of the catalogs was frozen at its transaction start
snapshot. We'd have to restrict it to read-only operation for safety,
but that's surely no problem for pg_dump. If we had that, then this
whole problem of server-side computations producing inconsistent
results would go away.
There might still be a window wherein tables visible at transaction start
could be dropped before AccessShareLock could be acquired, but I think
we could let pg_dump error out in that case.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
