From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pginfo <pginfo(at)t1(dot)unisoftbg(dot)com> |
Cc: | Richard_D_Levine(at)raytheon(dot)com, Michael Glaesemann <grzm(at)myrealbox(dot)com>, pgsql-sql(at)postgresql(dot)org, pgsql-sql-owner(at)postgresql(dot)org |
Subject: | Re: pg primary key bug? |
Date: | 2005-02-17 18:19:12 |
Message-ID: | 9340.1108664352@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
pginfo <pginfo(at)t1(dot)unisoftbg(dot)com> writes:
> Tom Lane wrote:
>> Could we see the system columns on these rows?
> 01=# select oid,xmin,cmin,xmax,cmax,ctid,* from a_constants_str where
> constname='DOCPLAID';
> oid | xmin | cmin | xmax | cmax | ctid | constname | fid |
> constvalue
> -------+---------+---------+---------+------+--------+-----------+-----+------------
> 17916 | 2232893 | 2235861 | 2235861 | 42 | (4,71) | DOCPLAID | 0 |
> SOF_19738
> 17916 | 2232893 | 2235861 | 2235861 | 41 | (7,62) | DOCPLAID | 0 |
> SOF_19738
> (2 rows)
Given the identical OID and xmin values, it seems certain that these are
the "same" row, ie there was only one insertion event. My bet is that
the one at (7,62) is the original, and that the one at (4,71) is a copy
that was made by VACUUM FULL trying to move the row to compact the
table. So the question is how did both copies get to be marked
simultaneously valid? That should be impossible, unless a disk write
got dropped. Have you had any system crashes during VACUUM FULL
operations recently?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-02-17 19:01:40 | Re: pg primary key bug? |
Previous Message | Richard Huxton | 2005-02-17 18:05:54 | Re: LOOP? |