Re: pg_dump --snapshot

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_dump --snapshot
Date: 2013-05-06 17:07:17
Message-ID: 8465.1367860037@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> On 6 May 2013 16:02, Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2013-05-06 17:12:38 Re: Commit subject line
Previous Message Magnus Hagander 2013-05-06 16:41:53 Re: Commit subject line