From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | John Sidney-Woollett <johnsw(at)wardbrook(dot)com> |
Cc: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Ever increasing OIDs - gonna run out soon? |
Date: | 2006-06-12 16:10:55 |
Message-ID: | 20060612161055.GD3829@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, Jun 12, 2006 at 05:02:09PM +0100, John Sidney-Woollett wrote:
> Jim C. Nasby wrote:
> > Except IIRC the OP is running 7.4 which doesn't have checks in DDL
> > code to deal with OID collisions. :(
>
> This is not good news! :(
>
> What about other long runing 7.4.x DBs? Do you really have to dump, init
> and restore every once in a while?
Well, you have to be using a lot of OIDs for this to be an issue. At
your stated rate of 1.5 million OIDs per day it will take just under
eight years before you wraparound. That's a lot of OIDs and most
databases don't get anywhere near that many, which is why it's not a
big deal for most people...
> Also, do you know what is actually using the OIDs - transactions?
Inserting new rows into a table somewhere that has OIDs. Just using
transactions won't do it. Note, some system catalogs use oids, so some
DDL statements can do it.
This gives you a list of tables that use OIDs. Maybe it can help you
track down the problem.
select attrelid::regclass from pg_attribute inner join pg_class on
(attrelid = oid) where attname = 'oid' and relkind = 'r';
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2006-06-12 16:47:04 | Re: Ever increasing OIDs - gonna run out soon? |
Previous Message | John Sidney-Woollett | 2006-06-12 16:02:09 | Re: Ever increasing OIDs - gonna run out soon? |