From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Duplicated oids between tables - problem or not? |
Date: | 2012-11-26 16:04:11 |
Message-ID: | 12544.1353945851@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Magnus Hagander <magnus(at)hagander(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavan Deolasee | 2012-11-26 16:05:05 | Re: Upcoming back-branch releases |
Previous Message | Peter Geoghegan | 2012-11-26 16:02:17 | Re: Materialized views WIP patch |