> From: Tom Lane <[EMAIL PROTECTED]> > Date: Wed, 09 Feb 2005 23:50:47 -0500 > To: Steve Lane <[EMAIL PROTECTED]> > Cc: "Joshua D. Drake" <[EMAIL PROTECTED]>, <[email protected]>, > Jesse LaVere <[EMAIL PROTECTED]> > Subject: Re: [ADMIN] PG 7.4: duplicate rows in violation of unique > > Steve Lane <[EMAIL PROTECTED]> writes: >> Sorry -- 7.4.5 > > I'm wondering if this could be related to this post-7.4.5 fix: > > 2004-10-13 18:22 tgl > > * contrib/pgstattuple/pgstattuple.c, > src/backend/access/heap/heapam.c, > src/backend/utils/adt/ri_triggers.c (REL7_4_STABLE): Repair > possible failure to update hint bits back to disk, per > http://archives.postgresql.org/pgsql-hackers/2004-10/msg00464.php. > > What you are describing sure sounds like a foulup in commit status > marking for multiple versions of a row. I'm not convinced it would be > fixed by the abovementioned patch, but it sounds close. By the way -- this problem looks very much like one I reported a few months ago. I'll replay that email here: > I'm hoping I'm wrong, but I think I'm looking at a corrupted table or > database. We have a column that's sequence-driven, with a unique index, but > we're seeing duplicate values in that column. We're also seeing duplicate OIDs > in the affected table. And we're seeing this ominous message: > > iep_db=# select distinct * into lavere_form_004 from iep_form_004; > ERROR: missing chunk number 0 for toast value 42551774 We're getting the same thing tonight -- same "missing chunk number XX for toast value YYYY." If this is some form of MVCC "leakage", can that also explain this error? Would the "leaked" rows somehow be incomplete in the sense of not linking correctly to their corresponding toast data? -- sgl ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
