Re: pg_dump --snapshot - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_dump --snapshot
Date
Msg-id 8465.1367860037@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_dump --snapshot  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: pg_dump --snapshot  (Andres Freund <andres@2ndquadrant.com>)
Re: pg_dump --snapshot  (Simon Riggs <simon@2ndQuadrant.com>)
Re: pg_dump --snapshot  (Robert Haas <robertmhaas@gmail.com>)
Re: pg_dump --snapshot  (Andres Freund <andres@2ndquadrant.com>)
List 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 by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Commit subject line
Next
From: Bruce Momjian
Date:
Subject: Re: Commit subject line