Re: Feature Request for 7.5
От | Peter Childs |
---|---|
Тема | Re: Feature Request for 7.5 |
Дата | |
Msg-id | Pine.LNX.4.58.0312031552070.1427@bluedragon.homelinux.net обсуждение исходный текст |
Ответ на | Re: Feature Request for 7.5 (Alvaro Herrera <alvherre@dcc.uchile.cl>) |
Ответы |
Re: Feature Request for 7.5
Re: Feature Request for 7.5 |
Список | pgsql-general |
On Wed, 3 Dec 2003, Alvaro Herrera wrote: > On Wed, Dec 03, 2003 at 08:41:40PM +0700, Chris Travers wrote: > > > It strikes me that, for many sorts of databases, multimaster synchronous > > replication is not the best solution for the reasons that Scott, Jan, et. > > al. have raised. I am wondering how commercial RDBMS's get arround this > > problem? > > Say, have you looked at the approach taken by postgres-r? It's supposed > to solve these problems, and unless I've missed something they are in > need of some manpower to port it to recent releases. > > I don't know the URL. It's on gborg somewhere though. > http://gborg.postgresql.org/project/pgreplication/projdisplay.php The way I under stand the fix is to have a two stage commit... This is from previous threads mind you. So its Client -> Server <Commit Transaction> Server -> Other Servers <Pre Commit> Other Servers -> Server <Ready to Commit> <Server Waits for all other servers to respond> Server -> Other Servers <Commit> Server -> Client <Commit Success or Not> Each query that makes a change needs to tell all other servers and get a responce. Oh yes and you need point in time backup to bring new servers up to date and crashed ones too. I really need point in time backup at the very least and would love to see all these features. These features are growing to beyond urgent now.... Less talk more action. Peter Childs
В списке pgsql-general по дате отправления: