| From: | Will LaShell <will(at)lashell(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org> |
| Subject: | Re: Using oid with RServ w/ Postgresql 7.2 |
| Date: | 2002-10-21 17:07:24 |
| Message-ID: | 1035220045.10930.25.camel@lyric.ofsloans.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
On Thu, 2002-10-17 at 18:55, Tom Lane wrote:
> Will LaShell <will(at)lashell(dot)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.
>
Just out of curiousity, when OID wraparound happens, won't there be
bigger problems?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2002-10-21 17:26:56 | Re: Using oid with RServ w/ Postgresql 7.2 |
| Previous Message | Jeff | 2002-10-21 16:24:21 | Re: Optimizing DB Permormanance |