Re: Better support of exported snapshots with pg_dump

On Wed, Oct 15, 2014 at 2:06 PM, Andres Freund <andres(at)2ndquadrant(dot)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