Re: Synchronized snapshots versus multiple databases - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Synchronized snapshots versus multiple databases
Date
Msg-id 22633.1319216762@sss.pgh.pa.us
Whole thread Raw
In response to Re: Synchronized snapshots versus multiple databases  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Synchronized snapshots versus multiple databases  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Andrew Dunstan <andrew@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?

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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [v9.2] Object access hooks with arguments support (v1)
Next
From: Tom Lane
Date:
Subject: Re: Synchronized snapshots versus multiple databases