Joachim Wieland <j...@mcknight.de> writes:
> On Tue, Dec 11, 2012 at 6:52 PM, Andres Freund <and...@2ndquadrant.com> wrote:
>> One problem I see is that while exporting a snapshot solves the
>> visibility issues of the table's contents it does not protect against
>> schema changes. I am not sure whether thats a problem.
>>
>> If somebody runs a CLUSTER or something like that, the table's contents
>> will be preserved including MVCC semantics. That's fine.
>> The more problematic cases I see are TRUNCATE, DROP and ALTER
>> TABLE.
> This is why the pg_dump master process executes a
> lock table <table> in access share mode
> for every table, so your commands would all block.
A lock doesn't protect against schema changes made before the lock was
taken. The reason that the described scenario is problematic is that
pg_dump is going to be expected to work against a snapshot made before
it gets a chance to take those table locks. Thus, there's a window
where DDL is dangerous, and will invalidate the dump --- perhaps without
any warning.
Now, we have this problem today, in that pg_dump has to read pg_class
before it can take table locks so some window exists already. What's
bothering me about what Andres describes is that the window for trouble
seems to be getting much bigger.
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
