X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 38E628B9F6B for ; Thu, 17 Feb 2005 18:19:21 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 94669-09 for ; Thu, 17 Feb 2005 18:19:13 +0000 (GMT) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by svr1.postgresql.org (Postfix) with ESMTP id 475478BA116 for ; Thu, 17 Feb 2005 18:19:13 +0000 (GMT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id j1HIJC6q009341; Thu, 17 Feb 2005 13:19:13 -0500 (EST) To: pginfo Cc: Richard_D_Levine@raytheon.com, Michael Glaesemann , pgsql-sql@postgresql.org, pgsql-sql-owner@postgresql.org Subject: Re: pg primary key bug? In-reply-to: <4214C94F.2050806@t1.unisoftbg.com> References: <4214B466.20908@t1.unisoftbg.com> <8125.1108661189@sss.pgh.pa.us> <4214C94F.2050806@t1.unisoftbg.com> Comments: In-reply-to pginfo message dated "Thu, 17 Feb 2005 17:41:51 +0100" Date: Thu, 17 Feb 2005 13:19:12 -0500 Message-ID: <9340.1108664352@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.007 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200502/199 X-Sequence-Number: 20310 pginfo 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