Re: pg_dump --snapshot

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_dump --snapshot
Дата
Msg-id 8465.1367860037@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_dump --snapshot  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: pg_dump --snapshot
Re: pg_dump --snapshot
Re: pg_dump --snapshot
Re: pg_dump --snapshot
Список pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:
> On 6 May 2013 16:02, Andrew Dunstan <andrew@dunslane.net> wrote:
>> On 05/06/2013 10:56 AM, Simon Riggs wrote:
>>> This overrides the internally generated snapshot in parallel pg_dump.

>> Could you be a bit more expansive about the use case, please?

> Exported snapshots allow you to coordinate a number of actions
> together, so they all see a common view of the database. So this patch
> allows a very general approach to this, much more so than pg_dump
> allows currently since the exact timing of the snapshot is not
> controlled by the user.

I'm afraid that this is institutionalizing a design deficiency in
pg_dump; namely that it takes its snapshot before acquiring locks.
Ideally that would happen the other way around.  I don't have a good
idea how we could fix that --- but a feature that allows imposition
of an outside snapshot will permanently foreclose ever fixing it.

What's more, this would greatly widen the risk window between when
the snapshot is taken and when we have all the locks and can have
some confidence that the DB isn't changing under us.

Or in short: -1 for the very concept of letting the user control
pg_dump's snapshot.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: Commit subject line
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Commit subject line