Re: Duplicated oids between tables - problem or not? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Duplicated oids between tables - problem or not?
Date
Msg-id 12544.1353945851@sss.pgh.pa.us
Whole thread Raw
In response to Duplicated oids between tables - problem or not?  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Duplicated oids between tables - problem or not?  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
Magnus Hagander <magnus@hagander.net> writes:
> I noticed after a pg_upgrade on a system, that the same oid is used
> both for a database and a user (repeated many times for different
> combinations of databases and users). This is because pg_upgrade
> doesn't preserve the database oid, and it reused the oid of the row in
> pg_authid.

> The reason I noticed this was that it confuses the hell out of
> pgadmin. This is clearly a bug in a SQL query pgadmin uses, and I'm
> going to go fix that.

> But is this something that can cause us problems somewhere else in the
> system? ISTM the same thing could happen after oid wraparound, but
> that pg_upgrade makes it a lot more likely to happen. So I'm thinking
> it shouldn't be a problem since the oid's are in different tables, but
> are there any other parts of the system where this could cause an
> actual problem?

It should not.  It's been understood for many years that uniqueness of
OIDs is only guaranteed within individual catalogs (by means of their
unique indexes on OID).  That's why mechanisms like pg_depend and
pg_description use catalog OID + object OID to identify objects.

We do insist that hand-assigned OIDs be globally unique, but that's just
for maintainers' sanity not because the code depends on it.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Materialized views WIP patch
Next
From: David Fetter
Date:
Subject: Re: Materialized views WIP patch