Re: Solving the OID-collision problem - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Solving the OID-collision problem
Date
Msg-id 1123540135.3670.439.camel@localhost.localdomain
Whole thread Raw
In response to Re: Solving the OID-collision problem  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Solving the OID-collision problem  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Solving the OID-collision problem  (Andrew Sullivan <ajs@crankycanuck.ca>)
List pgsql-hackers
On Mon, 2005-08-08 at 16:55 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.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




pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Simplifying wal_sync_method
Next
From: Simon Riggs
Date:
Subject: Re: Simplifying wal_sync_method