The group communication system doesn't just run on one system. For postgres-r using spreadb) The Group Communication blob will consist of a number of processes which need to talk to all of the others to interrogate them for changes which may conflict with the current write that being handled and then issue the transaction response. This is basically the two phase commit solution with phases moved into the group communication process. I can see the possibility of using solution b and having less group communication processes than databases as attempt to simplify things, but this would mean the loss of a number of databases if the machine running the group communication process for the set of databases is lost.
there is actually a spread daemon that runs on each database server. It has nothing to do with
detecting the conflicts. Its job is to deliver messages in a total order for writesets or simple order
for commits, aborts, joins, etc.
The detection of conflicts will be done at the database level, by a backend processes. The basic
concept is "if all databases get the writesets (changes) in the exact same order, apply them in a
consistent order, avoid conflicts, then one copy serialization is achieved. (one copy of the database
replicated across all databases in the replica)
I hope that explains the group communication system's responsibility.
Darren
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
