On Mon, Sep 1, 2014 at 6:30 PM, Andres Freund <and...@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_-4mfdxwhnastauhuq7u7uedd57vay28a...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
