Simon,
* Simon Riggs (simon@2ndQuadrant.com) wrote:
> 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?
Because parallel pg_dump didn't make the problem any *worse*..? This
does. The problem existed before parallel pg_dump.
> There is no risk that is larger than the one already exposed by the
> existing user API.
The API exposes it, yes, but *pg_dump* isn't any worse than it was
before.
> 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.
pg_dump uses it already and uses it as best it can. Users could use it
also, provided they understand the constraints around it. However,
there really isn't a way for users to use this new option correctly-
they would need to intuit what pg_dump will want to lock, lock it
immediately after their transaction is created, and only *then* get the
snapshot ID and pass it to pg_dump, hoping against hope that pg_dump
will actually need the locks that they decided to acquire..
Thanks,
Stephen
