Duplicate OIDs in pg_attribute - Mailing list pgsql-hackers

From Joe Mitchell
Subject Duplicate OIDs in pg_attribute
Date
Msg-id 3A80560E.F4D3749B@greatbridge.com
Whole thread Raw
Responses Re: Duplicate OIDs in pg_attribute  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
  <br />I noticed that pg_attribute has rows with the same OID!  You can <br />verify this by running. <p># select
count(oid),oidfrom pg_attribute group by oid having <br />count(oid) > 1; <p>We see that these duplicate OIDs appear
tohappen when <br />pg_attibute rows are inserted for indexes and primary keys. <p>select relname, attname <br />from
pg_attribute, pg_class <br />where attrelid = pg_class.oid and <br />pg_attribute.oid in (select oid <br
/>               from pg_attribute <br />                group by oid <br />                having count(oid) > 1);
<p>Isee: <br /><tt>                     relname             |   attname</tt><br /><tt>       
---------------------------------+--------------</tt><br/><tt>         pg_aggregate_name_type_index    |
aggname</tt><br/><tt>         pg_aggregate_name_type_index    | aggbasetype</tt><br /><tt>        
pg_amop_opid_index             | amopclaid</tt><br /><tt>         pg_amop_opid_index              | amopopr</tt><br
/><tt>        pg_amop_opid_index              | amopid</tt><br /><tt>         pg_amop_strategy_index          |
amopid</tt><br/><tt>         pg_amop_strategy_index          | amopclaid</tt><br /><tt>        
pg_amop_strategy_index         | amopstrategy</tt><br /><tt>         pg_attribute_relid_attnam_index | attrelid</tt><br
/><tt>        pg_attribute_relid_attnam_index | attname</tt><br /><tt>         pg_attribute_relid_attnum_index |
attrelid</tt><br/><tt>         pg_attribute_relid_attnum_index | attnum</tt><br /><tt>        
pg_inherits_relid_seqno_index  | inhrelid</tt><br /><tt>         pg_inherits_relid_seqno_index   | inhseqno</tt><br
/><tt>        pg_largeobject_loid_pn_index    | loid</tt><br /><tt>         pg_largeobject_loid_pn_index    |
pageno</tt><br/><tt>         pg_listener_pid_relname_index   | listenerpid</tt><br /><tt>        
pg_listener_pid_relname_index  | relname</tt><br /><tt>         pg_operator_oprname_l_r_k_index | oprname</tt><br
/><tt>        pg_operator_oprname_l_r_k_index | oprleft</tt><br /><tt>         pg_operator_oprname_l_r_k_index |
oprright</tt><br/><tt>         pg_operator_oprname_l_r_k_index | oprkind</tt><br /><tt>        
pg_proc_proname_narg_type_index| proname</tt><br /><tt>         pg_proc_proname_narg_type_index | pronargs</tt><br
/><tt>        pg_proc_proname_narg_type_index | proargtypes</tt><br /><tt>         pg_statistic_relid_att_index    |
starelid</tt><br/><tt>         pg_statistic_relid_att_index    | staattnum</tt><br /><tt>        
primarytest2_pkey              | col1</tt><br /><tt>         primarytest2_pkey               | col2</tt><br
/><tt>       (29 rows)</tt><p>What do people think about this issue?  It doesn't seem to have <br />major consequences
now,but it should probably be fixed?  When <br />system tables have referential integrity enforced, then it will be an
<br/>issue.  Can this be put on the TODO list? <p>Regards, <p>Joe Mitchell <br />Great Bridge LLC 

pgsql-hackers by date:

Previous
From: Karel Zak
Date:
Subject: Re: Include files for SPI are not installed
Next
From: Florent Guillaume
Date:
Subject: Re: [PATCHES] A Sparc/Linux patch (for 7.1), and a Linux rc.d/init.d script....