Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:
> Tom Lane wrote:
>> Throwing an error will definitely not do --- that'd mean your whole
>> installation comes to a screeching halt as soon as you hit 4G OIDs.
>> That cure is way worse than the disease...
> Is there really an alternative? There is no guarantee things will keep
> working after a wrap around. Some applications might, some might not
> depending on how they work. Isn't throwing an error better than
> continuing on, possibly doing the wrong thing?
No. Throwing an error (refusing to wrap the counter around) means that
you will refuse to create any more rows until after the dbadmin dumps,
initdbs, reloads. (If you think that's bad, consider also that in its
current form pg_dumpall would fail under those conditions, meaning you
couldn't even dump.) Stopping the whole DB dead in the water cannot
be a better answer than *anything*.
The main point of my prior post is that a well-designed DB will have
unique indexes to guarantee uniqueness of anything it needs to assume
is unique ... such as OIDs in particular tables. The presence of
those indexes might mean that individual transactions fail (when they
try to use a duplicate OID value), and that's surely nasty. But it's
not as nasty as forcibly shutting down ALL inserts, which is what
throwing an error implies.
Obviously this isn't a perfect, no-need-for-improvement approach.
We need 64-bit OIDs or the ability not to assign OIDs to tables that
don't need 'em before we can really say "problem solved". But throwing
an error on wraparound is *worse* than the laissez-faire approach we
take now. It's at least possible to design a DB to survive wraparound
now; if we throw an error survival is not possible.
regards, tom lane
