Re: [SQL] maximum number of rows in table - what about oid limits?

From: John Scott <jmscott(at)yahoo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, john(at)august(dot)com
Cc: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>, pgsql-general(at)postgresql(dot)org, pgsql-sql(at)postgresql(dot)org
Subject: Re: [SQL] maximum number of rows in table - what about oid limits?
Date: 2001-06-07 01:08:14
Message-ID: 20010607010814.72573.qmail@web10005.mail.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-sql


--- Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> John Scott <jmscott(at)yahoo(dot)com> writes:
> > my question is, since oid's are used by the
> > postgres kernel, what effect does oid wrapping have upon
> > the stability of the database.
>
> It doesn't affect stability, if by that you mean potential crashes.

yes and know. an application workaround is ok,

>
> What can happen after a wrap is that the OID generated for a
> newly-created object might conflict with some already-existing object's
> OID. If that happens, you get a duplicate-key-insertion error on the
> OID index of the relevant system catalog (pg_class, pg_type, etc).
> There is a unique index on OID for each system catalog wherein OID
> is used to identify objects. It doesn't really matter whether the
> same OID is reused in different catalogs or in user tables.

depends on how your are changing the catalog.
but does retrying fix the problem? wouldn't the second try just often
see the same oid again. does a failed attempt increment the oid????

>
> The odds of this happening seem pretty low, if you've got reasonable
> numbers of objects (eg, with a couple thousand tables in a database,
> you'd have a 2000/4G = 1 in 2 million chance of collision on pg_class
> OID). If it does happen, you can just retry the failed object-creation
> command until you get a nonconflicting OID assignment.

same argument as above.

all this sounds like a reasonable halfway solution.
i'm comfortable NOT using OID's at the application level for many reasons.
that's not a problem. i just don't want my imported, test database of 20B
tuples crashing for mysterious reasons, obviously, right out of the gate,
with me mumbling and
waving my hands at the wall. i can do that now with
commercial systems.

>
> This is certainly not ideal, but it's not nearly as big a problem as
> transaction ID wraparound. You can live with it, whereas right now
> xact ID wraparound is catastrophic. That we gotta work on, soon.

yep, 1000tx/sec ~~ 50 days before wrap.

by the way, have you written anything up on the txid wrapping problem?
we talked about this at osdn last year in san jose. i proposed
64 bits, and you discussed a clever wrapping algorithm involving 48 bits and,
if memory serves me, backward compatiablility of the disk format.
i was the one driving the car.

probably time to take this thread private?

cheers-john

>
> regards, tom lane

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Justin Clift 2001-06-07 01:18:54 USE_AUSTRALIAN_RULES breaks regression tests in 7.1.2?
Previous Message Lee Harr 2001-06-07 00:45:12 Re: Default value for bit datatype

Browse pgsql-sql by date

  From Date Subject
Next Message Stephan Szabo 2001-06-07 01:12:51 Re: behavior of ' = NULL' vs. MySQL vs. Standards
Previous Message Mark Stosberg 2001-06-07 01:00:45 behavior of ' = NULL' vs. MySQL vs. Standards