I have changed the text to reference "fail over" and "load balancing". 
I think it makes it clearer.  Let me know what you think.  I am hesitant
to mention commercial PostgreSQL products in our documentation.


Markus Schiltknecht wrote:
> Hello Bruce,
> Bruce Momjian wrote:
> > Here is a new replication documentation section I want to add for 8.2:
> > 
> >     ftp://momjian.us/pub/postgresql/mypatches/replication
> > 
> > Comments welcomed.
> Thank you, that sounds good. It's targeted to production use and 
> currently available solutions, which makes sense in the official manual.
> You are explaining the sync vs. async categorization, but I sort of 
> asked myself where the explanation of single vs multi-master has gone. I 
> then realized, that you are talking about read-only and a "read/write 
> mix of servers". Then again, you are mentioning 'Multi-Master 
> Replication' as one type of replication solutions. I think we should be 
> consistent in our naming. As Single- and Multi-Master are the more 
> common terms among database replication experts, I'd recommend to use 
> them and explain what they mean instead of introducing new names.
> Along with that, I'd argue that this Single- or Multi-Master is a 
> categorization as Sync vs Async. In that sense, the last chapter should 
> probably be named 'Distributed-Shared-Memory Replication' or something 
> like that instead of 'Multi-Master Replication', because as we know, 
> there are several ways of doing Multi-Master Replication (Slony-II / 
> Postgres-R, Distributed Shared Memory, 2PC in application code or the 
> above mentioned 'Query Broadcast Replication', which would fall into a 
> Multi-Master Replication model as well)
> Also in the last chapter, instead of just saying that "PostgreSQL does 
> not offer this type of replication", we could probably say that 
> different projects are trying to come up with better replication 
> solutions. And there are several proprietary products based on 
> PostgreSQL which do solve some kinds of Multi-Master Replication. Not 
> that I want to advertise for any of them, but it just sounds better than 
> the current "no, we don't offer that".
> As this documentation mainly covers production-quality solutions (which 
> is absolutely perfect), can we document the status of current projects 
> somewhere, probably in a wiki? Or at least mention them somewhere and 
> point to their websites? It would help to get rid of all those rumors 
> and uncertainties. Or are those intentional?
> Just my two cents.
> Regards
> Markus
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings

  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?


Reply via email to