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
