On 2014-10-15 14:28:16 +0900, Michael Paquier wrote: > On Wed, Oct 15, 2014 at 2:06 PM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
