Re: [mail] Re: Big 7.4 items - Replication

>
>
>
>b) 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.
>
The group communication system doesn't just run on one system.  For 
postgres-r using spread
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


>