From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Florian Pflug <fgp(at)phlo(dot)org>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Synchronized snapshots versus multiple databases |
Date: | 2011-10-21 17:06:02 |
Message-ID: | 22633.1319216762@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)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?
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.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-10-21 17:09:19 | Re: Synchronized snapshots versus multiple databases |
Previous Message | Robert Haas | 2011-10-21 16:56:11 | Re: [v9.2] Object access hooks with arguments support (v1) |