Re: Solving the OID-collision problem
От | Simon Riggs |
---|---|
Тема | Re: Solving the OID-collision problem |
Дата | |
Msg-id | 1123609263.3670.540.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: Solving the OID-collision problem (Richard Huxton <dev@archonet.com>) |
Ответы |
Re: Solving the OID-collision problem
|
Список | pgsql-hackers |
On Tue, 2005-08-09 at 16:01 +0100, Richard Huxton wrote: > Tom Lane wrote: > > > > What if there aren't any "untouched chunks"? With only 64K-chunk > > granularity, I think you'd hit that condition a lot more than you are > > hoping. Also, this seems to assume uniqueness across all tables in an > > entire cluster, which is much more than we want; it makes the 32-bit > > size of OIDs significantly more worrisome than when they only need to be > > unique within a table. > > Can I ask what happens if we end up re-using a recently de-allocated > OID? Specifically, can a cached plan (e.g. plpgsql function) end up > referring to an object created after it was planned: > > CREATE FUNCTION f1()... -- oid=1234 > CREATE FUNCTION f2()... -- oid=1235, calls f1() or oid=1234 > DROP FUNCTION f1() > CREATE FUNCTION f3()... -- re-uses oid=1234 Possible, but extremely unlikely... you'd have to keep a session open with a prepared query for as long as it takes to create a 4 billion tables... not a high priority case, eh? Best Regards, Simon Riggs
В списке pgsql-hackers по дате отправления: