Re: Big 7.1 open items - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Big 7.1 open items
Date
Msg-id 7872.961175318@sss.pgh.pa.us
Whole thread Raw
In response to Re: Big 7.1 open items  (The Hermit Hacker <scrappy@hub.org>)
List pgsql-hackers
The Hermit Hacker <scrappy@hub.org> writes:
> just to open up a whole new bucket of worms here, but ... if we do use OID
> (which up until this thought I endorse 100%) ... do we not run a risk if
> we run out of OIDs?  As far as I know, those are still a finite resource,
> no? 

They are, and there is some risk involved, but OID collisions in the
system tables will cause you just as much headache.  There's not only
the pg_class row to think of, but the pg_attribute rows, etc etc.

If you did have an OID collision with an existing table you'd have to
keep trying until you got a set of OID assignments with no conflicts.
(Now that we have unique indexes on the system tables, this should
work properly, ie, you will hear about it if you have a conflict.)
I don't think the physical table names make this noticeably worse.
Of course we'd better be careful to create table files with O_EXCL,
so as not to tromp on existing files, but we do that already IIRC.

> or, do we just assume that by the time that comes, everyone will be pretty
> much using 64bit machines? :)

I think we are not too far away from being able to offer 64-bit OID as
a compile-time option (on machines where there is a 64-bit integer type
that is).  It's just a matter of someone putting it at the head of their
todo list.

Bottom line is I'm not real worried about this issue.

But having said all that, I am coming round to agree with Hiroshi's idea
anyway.  See upcoming message.
        regards, tom lane


pgsql-hackers by date:

Previous
From: The Hermit Hacker
Date:
Subject: Re: AW: Big 7.1 open items
Next
From: Ed Loehr
Date:
Subject: planner question re index vs seqscan