Re: [Pgreplication-general] Master/Slave is in town! - Mailing list pgsql-general

From Andy Samuel
Subject Re: [Pgreplication-general] Master/Slave is in town!
Date
Msg-id 007b01c24f07$fc766c60$0200a8c0@edphgm
Whole thread Raw
List pgsql-general
This is certainly a good news !
Congratulations to you ( or to your team ) !!
I would like to personally say thank you for the great job !

Warmest regards
Andy

----- Original Message -----
From: "Mabrouk CHOUK" <mchouk@cs.mcgill.ca>
To: <pgreplication-general@gborg.postgresql.org>
Sent: Wednesday, August 28, 2002 9:09 PM
Subject: [Pgreplication-general] Master/Slave is in town!


> Hello All,
>
> I would like to announce that the Master/Slave approach to postgres is
> almost finished. I have presently a working system. I am presently testing
> the system and adding some "syntactic suger", i.e. making it nice and
> sweet.
>
> I am testing the new system on two solaris machines (one Master and one
> Slave). I will provide the new system for the general community for
> testing on a hopefully much larger cluster as soon as I wrap it up and
> have it approved by Dr. Bettina Kemme.
>
> There are many changes that I integrated into postgres. The main part of
> these changes are in the replication module, i.e. the replication manager
> process, the group communication process and the remote backends. This
> e-mail will be quite large if I have to describe all the changes. However,
> I have a suggestion: the replicationManager.c file have been dramatically
> reduced and simplified, to the point that I suggest renaming the new file
> to something like "MasterSlaveRMgr.c" or something alike. The reasons
> behind this is avoid confusion with the old update-everywhere file, and to
> make easier for developers to follow the changes to the system, and to
> make improvements to it if need be.
>
> The general direction of my near-future work will be the following:
>
> 1. failure over integration of both the Mater and any slave: the system
> has to be robust enough to handle failure of any host.
>
> 2. user transparent recovery mechanisms for both the Master and any Slave.
>
> I will be posting design suggestions on how I intend to pursue these two
> goals. As usual, any comments/suggestions that might help me design a
> better algorithm are very welcome.
>
> Cheers,
>
> Mabrouk
>
> _______________________________________________
> Pgreplication-general mailing list
> Pgreplication-general@gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/pgreplication-general
>




pgsql-general by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: Naming-scheme for db-files
Next
From: "David J. Trombley"
Date:
Subject: oid pseudoattribute in rules