Hmmm, you may consider contrib/dbmirror which provides replication without having to add any new column. but you still need to have at least one column as a "PRIMARY KEY".
I am trusting it in one of my production systems. Regds Mallah. > On Thu, 2002-10-17 at 18:55, Tom Lane wrote: >> Will LaShell <[EMAIL PROTECTED]> writes: >> > My question would then be, are there any problems/reasons or hints with using the >oid field >> > as the field that the rserv trigger is set on? We will be using rserv in a >production >> > environment so I'm looking at this as not just an academic solution but a real >world one. >> >> This is risky for a long-lived database. Things will work fine until the OID >counter wraps >> around (ie, more than 4 billion rows inserted into your database). After that you >have a risk >> of OID collisions. >> >> You can prevent the worst problems by installing a unique index on OID on each >replicated >> table; but then you may occasionally get unexpected "duplicate key" errors. >> >> My advice would be to add a serial8 column to each table and use that as the >replication >> primary key. >> > Hrmm, yea, I guess I was hoping to avoid the problem of adding a column to all of >our tables > that didn't really serve a purpose outside of being a replication id. > > Is rserv going to be moving into the core of Postgresql as the > replication system? If not, what type of replication is planned to be done. I know >that you > all are working on it and it is probably(?) your most requested feature next to >point in time > recovery. > > Does anyone know why rserve doesn't support/use multi-field keys for the replication >id? Or the > primary key if one is defined? I assume its for ease of coding? > > Sincerely, > Will LaShell ----------------------------------------- Get your free web based email at trade-india.com. "India's Leading B2B eMarketplace.!" http://www.trade-india.com/ ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
