Thanks for your comments.
I don't think we use OIDS in the application. Is the cluster command
dependent on OIDS at the row/tupple level?
Now that the application is live at our customers' site, have you any
suggestions on how we go about converting all of our permanent and
dynamically created app tables?
I am thinking of doing a schema dump and editing the file globally. Then a
schema load then a restore.
Is there a PG table I can update to achieve the same end?
Thanks again
Andrew Bartley
----- Original Message -----
From: "Neil Conway" <neilc@samurai.com>
To: "Andrew Bartley" <abartley@evolvosystems.com>
Cc: "PostgreSQL General" <pgsql-general@postgresql.org>
Sent: Monday, March 24, 2003 2:14 PM
Subject: Re: [GENERAL] 4 billion + oids
> On Sun, 2003-03-23 at 21:35, Andrew Bartley wrote:
> > 1. Change all creation of temp tables with "without oids", hoping
> > to reduce the consumption of OIDS
>
> That should be the first thing you should do (in 7.4, there will be an
> ALTER TABLE command to disable OIDs). If you're not making use of OIDs
> in your application, you can specify WITHOUT OIDS for all user tables.
> IMHO this should be the default for CREATE TABLE some time in the near
> future.
>
> > 1. Check for the error string "Cannot insert a duplicate key into
> > unique index pg_class_oid_index" in the batch shells for each
> > function call and re-run if required.
>
> If you define all your tables (especially temp tables) using WITHOUT
> OIDS, you shouldn't need to bother with this.
>
> > Can anyone comment if they know this is a fundamental limitation of
> > PostgreSQL
>
> It's not a "fundamental limitation" at all, merely a problem of
> remaining backward compatible with the behavior of previous PostgreSQL
> releases.
>
> > We are running PostgreSQL 7.2.1 on Pentium 4 x86 type systems.
>
> Upgrading to the latest stable 7.2 release (7.2.4), or if possible
> 7.3.2, is always encouraged.
>
> Cheers,
>
> Neil
>
>
>
