Re: OID/XID allocation (was Re: is PG able to handle a >500 GB Da tabase?) - Mailing list pgsql-general

From Bruce Momjian
Subject Re: OID/XID allocation (was Re: is PG able to handle a >500 GB Da tabase?)
Date
Msg-id 200101230049.TAA20349@candle.pha.pa.us
Whole thread Raw
In response to RE: OID/XID allocation (was Re: is PG able to handle a >500 GB Da tabase?)  ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>)
Responses Re: Re: OID/XID allocation (was Re: is PG able to handle a >500 GB Da tabase?)  (Peter Eisentraut <peter_e@gmx.net>)
List 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 by date:

Previous
From: "Mikheev, Vadim"
Date:
Subject: RE: OID/XID allocation (was Re: is PG able to handle a >500 GB Da tabase?)
Next
From: "Mitch Vincent"
Date:
Subject: 'plpgsql' oddity