|From:||Andres Freund <andres(at)2ndquadrant(dot)com>|
|To:||Michael Paquier <michael(dot)paquier(at)gmail(dot)com>|
|Cc:||Petr Jelinek <petr(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bernd Helmle <mailings(at)oopsware(dot)de>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Better support of exported snapshots with pg_dump|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2014-10-15 07:09:10 +0900, Michael Paquier wrote:
> > whatever replication solution you use and just have pg_dump accept the
> > snapshot as input parameter? I am not sure how much I like pg_dump creating
> > the slot. I am aware that you need to have the replication connection open
> > but that's IMHO just matter of scripting it together.
> The whole point of the operation is to reduce the amount of time the
> external snapshot is taken to reduce the risk of race conditions that
> may be induced by schema changes. See for example discussions related
> to why we do not authorize specifying a snapshot name as an option of
I think that's completely the wrong way to go at this. The time it takes
to create a replication slot under write load is far larger than the
time it takes to start pg_dump and load. This really doesn't add any
actual safety. Also, the inability to use the snapshot outside of
pg_dump restricts the feature far too much imo.
I personally think we should just disregard the race here and add a
snapshot parameter. The race is already there and not exactly
small. Let's not kid ourselves that hiding it solves anything.
But if that's not the way to go, we need to think about a way of how to
prevent "problematic" DDL that's not racy.
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
|Next Message||Stephen Frost||2014-10-15 05:22:59||Additional role attributes && superuser review|
|Previous Message||Noah Misch||2014-10-15 04:53:03||Re: narwhal and PGDLLIMPORT|