Re: Postgres-R: primary key patches - Mailing list pgsql-hackers

From Christopher Browne
Subject Re: Postgres-R: primary key patches
Date
Msg-id 87ljzut1ej.fsf@dba2.int.libertyrms.com
Whole thread Raw
In response to Re: Postgres-R: primary key patches  (Markus Wanner <markus@bluegap.ch>)
Responses Re: Postgres-R: primary key patches  (Markus Wanner <markus@bluegap.ch>)
Re: Postgres-R: primary key patches  (Dimitri Fontaine <dfontaine@hi-media.com>)
List pgsql-hackers
Markus Wanner <markus@bluegap.ch> writes:
> Thinking about index creation time doesn't make sense, as long as we
> still need a dump/restore cycle to setup replication. And even then,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> that operational issue has nothing to do with the question of hiding
> the newly generated index or not.

Let me note that one of the design criteria for Slony-I was to
explicitly NOT have such a requirement.

Making the assumption that it *is* acceptable to disrupt operations
for the duration of a dump/restore cycle is certain to limit interest
in a replication system.

A most pointed case where that will cause heartburn of the "I refuse
to use this" sort is if that disruption needs to take place when
recovering from the failure of a node.  That sort of disruption is
certainly counterproductive to the usual goal of replication enhancing
system availability.

Maybe I am misreading you; I rather hope so.
-- 
select 'cbbrowne' || '@' || 'linuxfinances.info';
http://cbbrowne.com/info/lsf.html
Rules  of the  Evil Overlord  #145. "My  dungeon cell  decor  will not
feature exposed pipes.  While they add to the  gloomy atmosphere, they
are good  conductors of vibrations and  a lot of  prisoners know Morse
code." <http://www.eviloverlord.com/>


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [patch] plproxy v2
Next
From: Simon Riggs
Date:
Subject: Plans for 8.4