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
> 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.
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?