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). 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, -- Michael
