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