Re: Logical decoding & exported base snapshot

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Logical decoding & exported base snapshot
Дата
Msg-id 26517.1355282418@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Logical decoding & exported base snapshot  (Joachim Wieland <joe@mcknight.de>)
Ответы Re: Logical decoding & exported base snapshot
Re: Logical decoding & exported base snapshot
Список 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 по дате отправления:

Предыдущее
От: David Gould
Дата:
Сообщение: Re: Strange errors from 9.2.1 and 9.2.2 (I hope I'm missing something obvious)
Следующее
От: Steve Singer
Дата:
Сообщение: Re: Logical decoding & exported base snapshot