Re: Postgres-R: primary key patches

Hi,

Christopher Browne wrote:
> Markus Wanner <markus(at)bluegap(dot)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.

That's a pretty cool feature, but hasn't been one of the primary design
goal of Postgres-R.

> 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.

I agree, that's certainly true.

> 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.

Huh? What does migration between major Postgres versions have to do with
node failures or recoveries?

System availability certainly *is* one of the primary design goals of
Posgres-R. Thus, once installed and running, you certainly don't need
any such procedure again. Certainly not due to node failures.

It would be nice if future upgrades (i.e. major version upgrades) of
single nodes could be done while the rest of the cluster is running.
That would mean having a pretty static binary change set communication
protocol, which works between different major Postgres versions. That's
certainly planned, but hey, we don't have a production ready version for
*any* major version, yet.

> Maybe I am misreading you; I rather hope so.

With an additional process and schema changes, Postgres-R takes quite a
different approach than Slony. I don't think that would have been
possible without forcing at least a Postmaster restart.

The schema changes are pretty minimal and can probably be done manually
(well, script driven, perhaps) before restarting with a Postmaster which
has replication compiled in. That would save the dump/restore cycle, but
certainly not the Postmaster restart.

However, with regard to the catalog version, Postgres-R can be thought
of as another major version of Postgres. (Maybe I should even extend the
catalog version with an 'R' or something, so as to prevent normal
Postgres version from running on a data directory of a Postgres-R
installation).

Regards

Markus