On Tue, Sep 28, 2010 at 11:14 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Another angle on this problem is that, at least AFAICT, the duplicate
>> OIDs are completely harmless so long as they are in different
>> catalogs. And if they are in the same catalog, then initdb will fail
>> (and shame on you if you don't notice that). Long, long ago
>> pg_description was indexed just by object-OID, so duplicates would be
>> a problem, but that hasn't been the case since 2001, and I'm not aware
>> of anything else that relies on OIDs being globally unique either. So
>> maybe we should decide that we just don't care about this any more.
>
> No, we shouldn't. The reason we still have the policy of global
> uniqueness of manually-assigned OIDs is that those OIDs frequently
> need to be copied in multiple places (eg, operators may need to be
> entered in pg_amop). It gets a lot easier to make mistakes, and
> harder to check for mistakes, if the OIDs aren't unique.
Yeah, I guess that's true.
> The duplicate_oids script is just something that committers are supposed
> to know to run when applying a patch that messes with the catalogs.
> That's a sufficiently small minority of patches that I don't see the
> attraction of trying to wire it into every build, nor every regression
> test. Maybe the landscape is changing to the point where we can't trust
> committers to get this right, but I haven't seen evidence of that. You
> certainly won't forget it again soon ;-)
Maybe so, but the more steps there are that have to be manually
remembered, the harder it gets. Run the regression tests, check for
duplicate OIDs, bump catversion, bump WAL version, bump pg_dump
archive version, bump pg_control version, check for unnecessary header
includes, audit trailing whitespace, look for leftovers that don't
need to be committed. If we can combine a step or two, it just makes
life easier.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company