Re: OID/XID allocation (was Re: is PG able to handle a >500 GB Da tabase?)
От | Bruce Momjian |
---|---|
Тема | Re: OID/XID allocation (was Re: is PG able to handle a >500 GB Da tabase?) |
Дата | |
Msg-id | 200101230049.TAA20349@candle.pha.pa.us обсуждение исходный текст |
Ответ на | RE: OID/XID allocation (was Re: is PG able to handle a >500 GB Da tabase?) ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>) |
Ответы |
Re: Re: OID/XID allocation (was Re: is PG able to handle
a >500 GB Da tabase?)
|
Список | pgsql-general |
[ Charset ISO-8859-1 unsupported, converting... ] > > Added to TODO: > > > > * Move OID retrieval into shared memory to prevent lose of > > unused oids > > Already implemented. But - up to 8192 oids may be lost in the event > of crash (ie without normal database shutdown when last fetched oid > is logged to WAL). TODO updated. > > Also, currently the oid can _not_ be used to determine the order rows > > were inserted because one backend can grab its block of 50 and another > > backend can start and insert a row first. > > Backends don't grab block of oids anymore. > > > If we could change this with litle risk, it would be nice to have in > > 7.1, but I am sure someone will object. :-) > > Too late to object -:)) > I had to make this changes for WAL. BTW, pg_variable is not used anymore > but still in schema - have to remove it someday. Added to TODO: * Remove unused pg_variable table -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
В списке pgsql-general по дате отправления: