Re: Solving the OID-collision problem

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Solving the OID-collision problem
Date: 2005-08-08 22:28:54
Message-ID: 1123540135.3670.439.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 2005-08-08 at 16:55 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > On Wed, 2005-08-03 at 19:43 -0400, Tom Lane wrote:
> >> We've sort of brushed this problem aside in the past by telling people
> >> they could just retry their transaction ... but why don't we make the
> >> database do the retrying? I'm envisioning something like the attached
> >> quick-hack, which arranges that the pg_class and pg_type rows for tables
> >> will never be given OIDs duplicating an existing entry.
>
> > I'd like to suggest that we backpatch this to 7.3 at least.
>
> Considering we don't even have code to do this, much less have expended
> one day of beta testing on it, back-patching seems a bit premature.

Tom,

You provided a patch and explained your testing of it. It seems to be a
useful test to me, and as I said a practical solution to OID wrap.

OID wrap is a long-term problem for PostgreSQL installations. I'm not
sure that lots of beta testing would do any good at all, since the
proposed patch is very unlikely to occur in 8.1, and almost certainly
not during a short period of beta testing.

As I mentioned, as time goes on, this is very likely to occur with older
installations before it occurs with newer ones. Older databases tend to
have older releases, hence the comment to backpatch. I regard this as a
safety/robustness feature, just as I would other robustness fixes that
have been backpatched without a beta test phase. If we have the code it
seems strange to wait for many people to start logging complaints before
we backpatch. I can see that will only lead to PostgreSQL's robustness
falling into disrepute, rather than encouraging anyone to upgrade.

In any case, if we choose not to backpatch now, we can at least discuss
a plan for it in the future? Planning is never premature, IMHO.

Best Regards, Simon Riggs

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Satoshi Nagayasu 2005-08-08 22:59:39 Re: enable/disable trigger (Re: Fwd: [HACKERS] Open items)
Previous Message Josh Berkus 2005-08-08 22:27:13 Re: Simplifying wal_sync_method