Hi,
Christopher Browne wrote:
Markus Wanner <[EMAIL PROTECTED]> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
