Re: 32bit OID wrap around concerns

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

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> 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 value creation is interleaved across several tables, so the shared
> generator does not have to skip too many values at once each time.

Yeah, I was just explaining that to some Salesforce colleagues. The fact
that we use a single shared OID generator (and not one per table) greatly
reduces the risk of long runs of consecutively-assigned OIDs in any one
table.

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. It might be worth tweaking the generation rules
to try to avoid that scenario. Still, there's not been any field
complaints indicating that this is a problem.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2015-03-02 20:47:04 Re: Idea: closing the loop for "pg_ctl reload"
Previous Message Tomas Vondra 2015-03-02 20:29:41 Re: Weirdly pesimistic estimates in optimizer