Re: Better support of exported snapshots with pg_dump
От | Robert Haas |
---|---|
Тема | Re: Better support of exported snapshots with pg_dump |
Дата | |
Msg-id | CA+TgmoYeYgb5DWwXKFUSR2P9+jqWA1SV496ZTTKs4DaXoKomYg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Better support of exported snapshots with pg_dump (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Better support of exported snapshots with pg_dump
|
Список | pgsql-hackers |
On Mon, Sep 1, 2014 at 5:30 AM, Andres Freund <andres@2ndquadrant.com> wrote: > Hi, > >> >Currently pg_dump does not allow a user to specify an exported snapshot >> >name that he would like to use for a dump using SET TRANSACTION SNAPSHOT >> >(now pg_export_snapshot is only used for parallel pg_dump within it). I >> >imagine that this would be handy to take a consistent dump of a given >> >database after creating a logical replication slot on it. Thoughts? > > Yes, I always wanted that option. I didn't find that option to be terribly important then, but I don't see how we can possibly get by without it now, unless our goal is to make logical decoding as hard to use as we possibly can. Tom's got a good point about the order of locking vs. snapshot taking, but I think the way to address that is by adding some capability to temporarily lock out all DDL on non-temporary objects across the entire system, rather than by trying to make pg_dump (or the walsender creating the replication slot) lock every table. Even if we could get that to work, it still leaves the very-much-related problem that dumps of databases containing many tables can easily exhaust the lock table. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: