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 <will@lashell.net> 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/