Re: Synchronized snapshots versus multiple databases

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

In response to

Responses

Browse pgsql-hackers by date

  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