Re: Peer to peer replication of Postgresql databases

For give me for responding to the beginning of this thread, but my
comments only apply to this post.

> already looked at ongoing work), in a peer to peer manner. The goal
> is to achive `nearly complete fault tolerence' by replicating data.

A worthy goal indeed!

> - Postmasters are running on different computers on a networked cluster.
> Their data areas are identical at the beginning and recide on local
> storage devices.
>
> - Each postmaster is aware that they are a part of a cluster and they
> can communicate with each other, send multicast requests and look for
> each other's presence (like heartbeat in linux-ha project).

These first two point on extending postmaster for a network cluster
and HA could be a bit tricky. Have you considered using a group
communication system like spread.org that already has the network
cluster and heartbeat built in?

> - There are two types of write queries. Postmasters use seperate
> communication channels for each. One is the sequencial channel which
> carries writes whose order is important, and the non-sequencial
> channel carries write queries whose order is not important.

This puts the burden of determining weather a conflict can happen on
the application or user. Application design could become a bit tricky.
If you plan to use the non-sequential channel in an application, you
would need to make sure there are never any possible conflicts.

>
> - When a frontend process sends non-sequencial write query to a backend,
> it is directly written to the local data area and a multicast is
> sent (preferably asynchronously) to the other postmasters who will
> also update their respective local areas.

What are you planning to send? (SQL, parsed statements, or tuples)

> - When a sequencial-write query is requested, the corresponding
> postmaster informs a main-postmaster (more about in the next point),
> waits for his acknowledgement, and proceeds the same way as the
> non-sequencial write.

This would make the main postmaster handle all the concurrency control for
the replicated system. Are you thinking a two phased commit protocol here?

>
> Or maybe we can completely ignore the main-postmaster concept and
> let the clients broadcast a request to obtain locks etc.

If each system can obtain locks, how will you handle deadlocks across
system boundaries?

>
> Suggessions and critisisms are welcome.
>

Have you taken a look at Postgres-R or the pg-replicaiton project. The goals
are the same as yours, and the approach is some what similar. There is
a mailing to discuss different approaches, and if you like what we are doing
you can certainly participate in the development.

http://gborg.postgresql.org/project/pgreplication/projdisplay.php

Regards

Darren