Steve King <steve.king@ecmsys.co.uk> writes:
> Files output from pg_filedump are below,
> I have two tables with duplicate oids and these are the pg_filedumps for
> them.

Hmm.  You seem to have a rather unusual usage pattern for these tables
--- it looks like there are *lots* of failed (rolled back) updates of
the same tuple.  Can you give us some details about the update commands
being issued against these tables?

As an example, the page from the "machine" table has many entries like
this:

 Item   9 -- Length:  261  Offset: 5288 (0x14a8)  Flags: USED
  OID: 9646238  CID: min(2) max(0)  XID: min(119186229) max(0)
  Block Id: 7  linp Index: 9   Attributes: 41   Size: 32
  infomask: 0x2a02 (HASVARLENA|XMIN_INVALID|XMAX_INVALID|UPDATED) 

which is evidently a failed (aborted) update of the row with OID
9646238.  There are 27 other items on the same page with different
XIDs --- all failed commands, according to the XMIN_INVALID bits ---
and these two:

 Item  10 -- Length:  261  Offset: 7928 (0x1ef8)  Flags: USED
  OID: 9646238  CID: min(5) max(2)  XID: min(119162725) max(119208868)
  Block Id: 759  linp Index: 30   Attributes: 41   Size: 32
  infomask: 0x2902 (HASVARLENA|XMIN_COMMITTED|XMAX_INVALID|UPDATED) 

 Item  18 -- Length:  261  Offset: 7664 (0x1df0)  Flags: USED
  OID: 9646238  CID: min(2) max(2)  XID: min(119162754) max(119208939)
  Block Id: 760  linp Index: 3   Attributes: 41   Size: 32
  infomask: 0x2902 (HASVARLENA|XMIN_COMMITTED|XMAX_INVALID|UPDATED) 

These are both still valid (since their attempted deleting transactions
both rolled back, according to the XMAX_INVALID bits).  But how did
transactions 119162725 and 119162754 both manage to commit updates of
the same row, without one invalidating the other?

I wonder whether this is evidence of a race condition in the
concurrent-update logic.  Can't tell without much more detail, though.

			regards, tom lane

Mon, 16 Dec 2002 18:07:05 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: FW: Duplicate oids! 