On 2014-10-15 14:28:16 +0900, Michael Paquier wrote:
> On Wed, Oct 15, 2014 at 2:06 PM, Andres Freund <andres@2ndquadrant.com>
> wrote:
>
> > 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.
> >
>
> Well, I would be perfectly happy to be able to specify a snapshot for
> pg_dump, now the reason why this approach is used is to be able to isolate
> the DDL conflicts into pg_dump itself without relying on any external
> mechanism, be it an extra client controlling lock on the objects being
> dumped, or a system-wide lock preventing any DDL command (LOCK SYSTEM kind
> of thing).
There's no 'isolation' here imo. pg_dump *does not* detect these
cases. I've posted a couple of examples of that in some earlier thread
about this.
> This seems more user-friendly. But well I agree that we could do
> a larger set of things that could be used for even other purposes:
> - Ability to define snapshot name with pg_dump
> - Take system or database-wide lock
> - Extra client application running the whole
> Now is this set of features worth doing knowing that export snapshot has
> been designed for multi-threaded closed applications? Not much sure.
> Regards,
What do you mean with "designed for multi-threaded closed applications"?
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
