Re: Logical decoding & exported base snapshot - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Logical decoding & exported base snapshot
Date
Msg-id 26517.1355282418@sss.pgh.pa.us
Whole thread Raw
In response to Re: Logical decoding & exported base snapshot  (Joachim Wieland <joe@mcknight.de>)
Responses Re: Logical decoding & exported base snapshot
Re: Logical decoding & exported base snapshot
List pgsql-hackers
Joachim Wieland <joe@mcknight.de> writes:
> On Tue, Dec 11, 2012 at 6:52 PM, Andres Freund <andres@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



pgsql-hackers by date:

Previous
From: David Gould
Date:
Subject: Re: Strange errors from 9.2.1 and 9.2.2 (I hope I'm missing something obvious)
Next
From: Steve Singer
Date:
Subject: Re: Logical decoding & exported base snapshot