Re: Synchronized snapshots versus multiple databases

Поиск
Список
Период
Сортировка
От Florian Pflug
Тема Re: Synchronized snapshots versus multiple databases
Дата
Msg-id B9188FCB-5E75-4BC3-815D-2F564C267B8D@phlo.org
обсуждение исходный текст
Ответ на Synchronized snapshots versus multiple databases  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Synchronized snapshots versus multiple databases
Re: Synchronized snapshots versus multiple databases
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: ProcessStandbyHSFeedbackMessage can make global xmin go backwards
Следующее
От: Tom Lane
Дата:
Сообщение: Re: funny lock mode in DropTrigger