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

From Florian Pflug
Subject Re: Synchronized snapshots versus multiple databases
Date
Msg-id B9188FCB-5E75-4BC3-815D-2F564C267B8D@phlo.org
Whole thread Raw
In response to Synchronized snapshots versus multiple databases  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Synchronized snapshots versus multiple databases
Re: Synchronized snapshots versus multiple databases
List pgsql-hackers
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?

On that grounds, +1 for option 1 here.

> 3. Remove the optimization that lets GetOldestXmin ignore XIDs outside
> the current database.  This sounds bad, but OTOH I don't think there's
> ever been any proof that this optimization is worth much in real-world
> usage.  We've already had to lobotomize that optimization for walsender
> processes, anyway.

Hm, we've told people who wanted cross-database access to tables in the
past to either
 * use dblink or
 * not split their tables over multiple databases in the first place,   and to use schemas instead

If we remove the GetOldestXmin optimization, we're essentially reversing
course on this. Do we really wanna go there?

best regards,
Florian Pflug



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: ProcessStandbyHSFeedbackMessage can make global xmin go backwards
Next
From: Tom Lane
Date:
Subject: Re: funny lock mode in DropTrigger