Re: Better support of exported snapshots with pg_dump

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Bernd Helmle <mailings(at)oopsware(dot)de>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Better support of exported snapshots with pg_dump
Date: 2014-09-01 09:30:52
Message-ID: 20140901093052.GB7400@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2014-09-01 10:25:58 +0200, Bernd Helmle wrote:
> --On 1. September 2014 17:00:32 +0900 Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
>
> >Currently pg_dump does not allow a user to specify an exported snapshot
> >name that he would like to use for a dump using SET TRANSACTION SNAPSHOT
> >(now pg_export_snapshot is only used for parallel pg_dump within it). I
> >imagine that this would be handy to take a consistent dump of a given
> >database after creating a logical replication slot on it. Thoughts?

Yes, I always wanted that option.

> There was a discussion of this kind of feature some time ago here:
>
> <http://www.postgresql.org/message-id/CA+U5nMK9+TTCff_-4MfdxWHnASTAuHuq7u7uedD57vaY28AsQA@mail.gmail.com>

I was never convinced of the reasoning in that thread. Possibly things
have changed enough now that logical decoding is in core...

> Not sure if all the arguments holds still true with the appearance of MVCC
> catalog scans.

I don't think they change anything here. The problem is the, pretty
fundamental, problem that you need to know a relation exists before
executing a LOCK ...; on it. During that time somebody can change the
schema.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2014-09-01 09:52:30 Re: [Fwd: Re: proposal: new long psql parameter --on-error-stop]
Previous Message Andres Freund 2014-09-01 09:24:42 Re: PL/pgSQL 2