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,