Re: Peer to peer replication of Postgresql databases - Mailing list pgsql-hackers

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