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