Re: pg primary key bug?

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

In response to

Responses

Browse pgsql-sql by date

  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?