From: | Florian Pflug <fgp(at)phlo(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Synchronized snapshots versus multiple databases |
Date: | 2011-10-21 16:05:03 |
Message-ID: | B9188FCB-5E75-4BC3-815D-2F564C267B8D@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-10-21 16:19:35 | Re: funny lock mode in DropTrigger |
Previous Message | Tom Lane | 2011-10-21 15:59:39 | Re: ProcessStandbyHSFeedbackMessage can make global xmin go backwards |