Thread: OID rollover?

What happens to my database when the OID rolls over?

If the answer is "doom", is there anything I can do about it?

> What happens to my database when the OID rolls over?
>
> If the answer is "doom", is there anything I can do about it?
>

Actually, no one has every reported a roll-over, so I can't say for
sure.  They are unsigned ints, so it should go past 2 gigs.  If it goes
past 4 gigs, it rolls to zero again.  Having duplicate oids in the same
table is really not a crisis, though there could be come oid collision
in the system tables that could cause problems.

--
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

On Sun, 9 Apr 2000, Charles Martin wrote:

> What happens to my database when the OID rolls over?

A simple-minded calculation yields that you would have to create about 1
million new (not updated) records every day for more than 10 years to
exhaust the oid space. By the time that becomes a problem we'll all have
64 bit machines in anticipation of Y2038 anyway.

> If the answer is "doom", is there anything I can do about it?

Dump and reload your database. Unless you are actually *using* all of them
(in which case you'd need more than 100 GB to simply store the tuple
control structures), then "doom" is a feature. :)

--
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden

At 01:54 PM 10-04-2000 +0200, Peter Eisentraut wrote:
>On Sun, 9 Apr 2000, Charles Martin wrote:
>
>> What happens to my database when the OID rolls over?
>
>A simple-minded calculation yields that you would have to create about 1
>million new (not updated) records every day for more than 10 years to
>exhaust the oid space. By the time that becomes a problem we'll all have
>64 bit machines in anticipation of Y2038 anyway.

So if I'm a hotmail wannabe and I have 100000 users and the average user
receives 50 emails a day (half spam ;) ), in two years I'm in trouble?

And that's if they don't compose any emails or do anything else and the
OIDs increment only by one each time. If the OIDs increase by much more
than one, I'm in big trouble with a lot fewer users.

What I noticed is that when you start a new database connection, the OID
starting numbers jump to the next block of 32 numbers. Within the session,
the OIDs are gradually incremented - even if there are rollbacks, the OID
numbers do jump to the next block to avoid other used OIDs.

Fortunately I use persistent database connections, so the big jumps should
not happen so often, but what really happens when the OID rolls over? Do
the unused/skipped OIDs get used without any problems? Or will postgres go
postal?

>> If the answer is "doom", is there anything I can do about it?
>Dump and reload your database. Unless you are actually *using* all of them

Ow. So it will really be doom??

Will there be any early warnings of doom? e.g. The faithful going about
proclaiming "Reload for The End is Near!" (surrounded by daemons and being
killed of course).

Cheerio,

Link.

p.s. Doom™ Id Software :).