On 10/21/2011 01:06 PM, Tom Lane wrote:
Andrew Dunstan<and...@dunslane.net> writes:
On 10/21/2011 12:05 PM, Florian Pflug wrote:
On Oct21, 2011, at 17:36 , Tom Lane wrote:
1. Restrict exported snapshots to be loaded only by transactions running
in the same database as the exporter. This would fix the problem, but
it cuts out one of the main use-cases for sync snapshots, namely getting
cluster-wide-consistent dumps in pg_dumpall.
Isn't the use-case getting consistent *parallel* dumps of a single database
rather than consistent dump of multiple databases? Since we don't have atomic
cross-database commits, what does using the same snapshot to dump multiple
databases buy us?
That was my understanding of the use case.
Um, which one are you supporting?
#1 seemed OK from this POV. Everything else looks ickier and/or more
fragile, at first glance anyway.
Anyway, the value of using the same snapshot across all of a pg_dumpall
run would be that you could be sure that what you'd dumped concerning
role and tablespace objects was consistent with what you then dump about
database-local objects. (In principle, anyway --- I'm not sure how
much of that happens under SnapshotNow rules because of use of backend
functions. But you'll most certainly never be able to guarantee it if
pg_dumpall can't export its snapshot to each subsidiary pg_dump run.)
For someone who is concerned with that, maybe pg_dumpall could have an
option to take an EXCLUSIVE lock on the shared catalogs?
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
