Re: contrib/dbmirror
От | Jan Wieck |
---|---|
Тема | Re: contrib/dbmirror |
Дата | |
Msg-id | 40F040C7.7020002@Yahoo.com обсуждение исходный текст |
Ответ на | Re: contrib/dbmirror (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-patches |
On 7/1/2004 12:39 AM, Tom Lane wrote: > Joe Conway <mail@joeconway.com> writes: >> ssinger@navtechinc.com wrote: >>> Attached is a 1 line bug fix for dbmirror that was submitted. >>> It fixes a bug where some transactions could be dropped when writing >>> mirrored SQL statements to files. > >> I know that there were discussions regarding removing the replication >> contribs (rserv and dbmirror) prior to 7.5 release, but given that that >> has not happened yet, any objections to me applying this? > > There was talk of removing rserv, because it's seriously obsolete and > not maintained, but I don't think the same argument applies to > dbmirror. Patch away. There was never any intention to remove them. They should be relocated to the pgfoundry. The reason for this is that up to today, people looking for replication solutions find rserv in contrib and waste time with it. Others try dbmirror and later on apply their "results with trigger based replication" to Slony and think "must be slow". dbmirror is well maintained, and I know that it can and will do things that Slony is not planned to do (like keyrange based partial replication). It should be kept, but from the past discussions we know that contrib is a location that makes a lot of people assume that those things are recommended, preferred or some such. Jan > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
В списке pgsql-patches по дате отправления: