On Mon, Mar 2, 2015 at 12:38 PM, Tom Lane wrote:
>
> There is an issue if you do a dump and restore: the toast OIDs used in any
> one table will be consecutive after that, because we load all the data for
> each table sequentially.
With these consecutive oids, the "aggravated oid wrap around" can
Alvaro Herrera writes:
> Qingqing Zhou wrote:
>> Do we think above scenario is something we shall worry about? Especially
>> for large databases.
> IMO in theory it sucks that toast values use the shared OID generator,
> though in practice I have never seen a problem due to that. Often,
> toast
Qingqing Zhou wrote:
> One scenario is to use an oid to identify a toast value. As the oid
> generation is mono increased within a database instance, it can gets wrap
> around after 2^32 generations. After that:
> 1. GetNewOidWithIndex() could gets unbounded performance as it needs to by
> pass alr
One scenario is to use an oid to identify a toast value. As the oid
generation is mono increased within a database instance, it can gets wrap
around after 2^32 generations. After that:
1. GetNewOidWithIndex() could gets unbounded performance as it needs to by
pass already in use values of its own.
