Re: pg_dump --snapshot
От | Simon Riggs |
---|---|
Тема | Re: pg_dump --snapshot |
Дата | |
Msg-id | CA+U5nMKCBxg+26-KFw0-AGyno8-114uq6qyKpCzcoUH6Di09Vw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_dump --snapshot (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_dump --snapshot
|
Список | pgsql-hackers |
On 6 May 2013 22:13, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: >> It does *not* pass in a raw snapshot. All it does is to allow pg_dump >> to use an API that is already exposed by the backend for this very >> purpose, one that has been in Postgres since 9.2. >> http://www.postgresql.org/docs/devel/static/functions-admin.html#FUNCTIONS-SNAPSHOT-SYNCHRONIZATION > >> Minor patch, no amazing new functionality, no drama. > > You're ignoring the objection ... No, I just don't see a problem at all. Locks and snapshots have got nothing to do with each other, in Postgres. Taking a snapshot doesn't imply that database objects are locked; whoever takes the snapshot should lock things first, if they are worried by that. If anybody really wanted to fix pg_dump, they could do. If that was so important, why block this patch, but allow parallel pg_dump to be committed without it? There is no risk that is larger than the one already exposed by the existing user API. If you do see a risk in the existing API, please deprecate it and remove it from the docs, or mark it not-for-use-by-users. I hope you don't, but if you do, do it now - I'll be telling lots of people about all the useful things you can do with it over the next few years, hopefully in pg_dump as well. --Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: