From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)2ndquadrant(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_dump --snapshot |
Date: | 2013-05-07 00:18:26 |
Message-ID: | 20130507001826.GN4361@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon,
* Simon Riggs (simon(at)2ndQuadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | mark.kirkwood | 2013-05-07 00:23:58 | Re: In progress INSERT wrecks plans on table |
Previous Message | Simon Riggs | 2013-05-06 23:25:51 | Re: pg_dump --snapshot |