Attached is a reasonably complete working-out of my earlier proposal to prevent OID collisions by probing catalogs' OID indexes and advancing to the next OID whenever there is a duplicate. The code is driven by the existence of a unique index, and so it is possible for users to take advantage of the feature too:
create table foo(...) with oids; create unique index foo_oid on foo(oid); I'm not sure if we really want to document that though, as the implementation will perform poorly when there are long runs of consecutive OIDs in the table. This is relatively unlikely in the system catalogs but seems quite probable in a user table. The patch also removes CheckMaxObjectId, which seems no longer needed. If we commit it, we should remove the code in pg_dump that tries to set the OID counter, since that'd be dead code; but I didn't include that change in this patch. Documentation updates are lacking too. In principle I think this could be back-patched as far as 7.2, since RelationGetIndexList exists that far back, but of course it needs a good deal of testing before we even think about that. (There are a couple of aspects that depend on the recent changes to have fixed, preassigned OIDs for system catalogs, and we'd have to tweak those areas to make a back-patch.) Comments? regards, tom lane
binllTLVzLsFX.bin
Description: unique_oids.patch.gz
---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings