Re: 32bit OID wrap around concerns

From: Qingqing Zhou <zhouqq(dot)postgres(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 32bit OID wrap around concerns
Date: 2015-03-02 21:00:31
Message-ID: CAJjS0u0CVbKn5GQbmybyxt-2xaMtiuHC0O18i0wsg3UmYaJ7wQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 2, 2015 at 12:38 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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 be
illustrated by the following example:
- table A oids in [minOid, 2^31)
- table B oids in [2^31, 2^32]

After 1st time wrap around, and follows an insert(A), it immediately
bumps oid to 2^31. Now it is B's turn, it has to bump it to 2^32 and
wrap it around the 2nd time. This extreme example shows that we can
incur another wrap around with 2 toast insertions.

It is not clear how above example can be translated into real world
scenario probabilistically ("many more interleaved ranges (down) with
many more concurrency (up)"), but the "aggravated" issue seems there.

Regards,
Qingqing

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2015-03-02 21:21:48 Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} 2.0
Previous Message Andres Freund 2015-03-02 20:57:59 autogenerated column names + views are a dump hazard