On Mon, Sep 1, 2014 at 6:30 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2014-09-01 10:25:58 +0200, Bernd Helmle wrote:
>> 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>
Thanks. It is not surprising to see similar threads.
> I was never convinced of the reasoning in that thread. Possibly things
> have changed enough now that logical decoding is in core...
Well, the test case I got in mind is only for taking a dump using the
latest state of a replication slot and not the snapshot export itself.
So what about the following: we let the user specify a slot name with
pg_dump, and take a dump using the latest snapshot that this
replication slot has reported to a user. We could track the name of
the latest snapshot reported to user by adding a new field in
MyReplicationSlot, field updated in walsender.c when calling
SnapBuildExportSnapshot. Then we could expose that in
pg_replication_slots or with a separate SQL function that pg_dump
could use. That's just a rough idea, but something like that would
greatly help users writing online upgrade scripts.
>> 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.
Doesn't this window exist as well with parallel pg_dump? Looking at
the code snapshot export is taken before any locks on tables are
taken. This window is smaller, but still...
--
Michael