Re: Big 7.1 open items

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: The Hermit Hacker <scrappy(at)hub(dot)org>
Cc: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Big 7.1 open items
Date: 2000-06-16 17:08:38
Message-ID: 7872.961175318@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

The Hermit Hacker <scrappy(at)hub(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ed Loehr 2000-06-16 17:38:01 planner question re index vs seqscan
Previous Message The Hermit Hacker 2000-06-16 16:58:03 Re: AW: Big 7.1 open items

Browse pgsql-patches by date

  From Date Subject
Next Message Don Baccus 2000-06-16 17:50:23 Re: Big 7.1 open items
Previous Message Tom Lane 2000-06-16 16:54:00 Re: Big 7.1 open items