On 6 May 2013 22:13, Tom Lane <t...@sss.pgh.pa.us> wrote: > Simon Riggs <si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
