From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Philip Warner <pjw(at)rhyme(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: heap_create with OID? |
Date: | 2000-07-06 14:55:41 |
Message-ID: | 29283.962895341@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>> 2. Run the system long enough, the OID counter will wrap around and
>> start generating already-used numbers.
> Seems we should throw an error on rollover, or at least jump from 0 to
> 17k to skip the system oid's. That zero oid is going to cause a
> problem, perhaps.
Throwing an error will definitely not do --- that'd mean your whole
installation comes to a screeching halt as soon as you hit 4G OIDs.
That cure is way worse than the disease...
We do need to avoid generating a zero OID. I vaguely recall having
seen some code somewhere that did that, but it was pretty crude/ugly,
and I'm not even sure it was in the OID generator rather than in one
specific routine that used OIDs :-(. (What I seem to recall having
seen was some code that called newoid() a second time if it got a zero.
This is bletcherous of course.)
As long as we've gotta avoid zero anyway, skipping over the whole
system-reserved range doesn't sound like a bad idea, even though it's
not going to guarantee anything. But it's got to be done at the bottom
level of the counter-incrementing logic, not higher up.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Poole | 2000-07-06 15:55:16 | Re: [HACKERS] Re: Revised Copyright: is this more palatable? |
Previous Message | Tom Lane | 2000-07-06 14:39:06 | Re: PostgreSQL & the BSD License |