Simon, * Simon Riggs (si...@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
signature.asc
Description: Digital signature