Re: pg primary key bug? - Mailing list pgsql-sql

From Tom Lane
Subject Re: pg primary key bug?
Date
Msg-id 9340.1108664352@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg primary key bug?  (pginfo <pginfo@t1.unisoftbg.com>)
List pgsql-sql
pginfo <pginfo@t1.unisoftbg.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


pgsql-sql by date:

Previous
From: Richard Huxton
Date:
Subject: Re: LOOP?
Next
From: pginfo
Date:
Subject: Re: pg primary key bug?