Re: Big 7.1 open items
От | Tom Lane |
---|---|
Тема | Re: Big 7.1 open items |
Дата | |
Msg-id | 7872.961175318@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Big 7.1 open items (The Hermit Hacker <scrappy@hub.org>) |
Список | 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 по дате отправления: