On Fri, 2011-02-11 at 08:35 -0500, Daniel Popowich wrote:
> think no software process can make anyone happy. It's a human
> process: declare someone the owner of the database schema, let them
> own the long term development of the schema, and if anyone needs a
> change, they have to communicat
cified as succinctly as possible, and
everything else around it should be automatic.
> - Creating a new column based on an old one, and removing the old one;
> eg. add a column "n", run "UPDATE ... SET n = i*j * 2", and then drop
> the old columns "i" and &qu
way to run all the transactions for a
> single server for all databases within it on a single (or small number) of
> connections?
It would be easy to extend the ChronicDB live database schema update
system to support an atomic schema change across a multitude of
databases.
> Is there a better w
This example is certainly a workable situation. However it does require
understanding the constraints of an ALTER TABLE statement and manually
developing appropriate scripts.
The update model offered my ChronicDB accounts for schema changes of
considerable complexity, such as merging fields
Jeff,
One way to address the indefinite locking due to an ALTER TABLE
statement for PostgreSQL is to use ChronicDB. It allows you to apply
such a schema change live, without bringing down the database.
The space requirements for applying the live schema change would be to
have at least twice as
Hello,
We have been developing a high-availability and
version control solution for Postgres, called
ChronicDB[1], that aims to combine live schema
changes, replication, live connection migration,
and scalability in a cohesive manner. We are
requesting feedback[2] on the most desireable
features
Dear PostgreSQL Users,
We would like to announce a new technology called
ChronicDB[1] that aims to update databases (both
their data and their schemas) while they are
running live, without bringing the database down
at all.
The main focus of ChronicDB is to completely
eliminate downtime in the
