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
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 |