"Mason Hale" <[EMAIL PROTECTED]> writes: > I found a single pair of rows that were duplicated. Interestingly it was not > just the guid and feed_id that were duplicated but all columns were > indentical, including the primary key, except an update_at column which is > automatically populated via a trigger (BEFORE UPDATE on entry FOR EACH ROW).
> The duplicate data included a created_at column which defaults to now() -- > that the two duplicate rows have exactly the same values strongly hints to > me that the duplicates were created during the same transaction. Hmm, what sounds more likely to me is that both of those rows are updated versions of the same original row. > Here's the system column data you requested. > id | ctid | xmin | xmax | cmin | cmax > -----------+--------------+------+------+------+------ > 151341072 | (1508573,11) | 2 | 0 | 19 | 0 > 151341072 | (1818219,11) | 2 | 0 | 19 | 0 > (2 rows) I wonder whether it's just a coincidence that these have the same offset number... The fact that both rows have been frozen (xmin=2) means we can't really tell whether they originated in the same transaction or not. Can you show us all the triggers on this table? Also, it would be real interesting to see "pg_filedump -i -f" output for the two blocks in question (1508573 and 1818219) --- see http://sources.redhat.com/rhdb/ to get a copy of pg_filedump. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
