From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joe Mitchell <jmitchell(at)greatbridge(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Duplicate OIDs in pg_attribute |
Date: | 2001-02-07 00:46:44 |
Message-ID: | 26644.981506804@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Joe Mitchell <jmitchell(at)greatbridge(dot)com> writes:
> I noticed that pg_attribute has rows with the same OID!
Joe previously asked me about this off-list, and I replied thus:
This appears to be due to the incredibly grotty coding used in
AppendAttributeTuples in src/backend/catalog/index.c --- rather than
building tuples in any of several sane fashions, it's using an unholy
combination of memmove and heap_modifytuple to update a single tuple
object into successive states that correspond to the rows it needs to
add to the table. Unfortunately the OID assigned by the first
heap_insert gets carried along to the subsequent states, so the later
calls to heap_insert don't think they should assign new OIDs.
Good catch, Joe! This bug has probably been there since the beginning
of time. It's evidently got no serious consequences (since in reality,
OID uniqueness is not assumed for this table), but it ought to be fixed.
A quick-hack solution would be to zero out the tuple's OID before each
heap_insert, but really AppendAttributeTuples should be rewritten to
construct each tuple independently in the first place.
A quick 'glimpse' shows no other uses of heap_modifytuple except to
update an existing tuple, so evidently no one was foolish enough to
copy this technique.
I recommend putting this on the TODO for 7.2. We can't fix it now
unless we want to force an initdb.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2001-02-07 00:50:42 | Re: Include files for SPI are not installed |
Previous Message | Tom Lane | 2001-02-07 00:43:10 | Re: Re: [SQL] PL/PGSQL function with parameters |