Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> On Sun, 16 Nov 2003, Joel Jacobson wrote:
>> oid | xmin | xmax | userid | balance | reservedbalance |
>> modificationdate
>> ---------+-----------+-----------+---------+----------+-----------------+------------------
>> 2080463 | 248152344 | 248307452 | 1002024 | 10000.00 | 154.02 |
>> 1068947725
>> 2080463 | 248274508 | 248307402 | 1002024 | 10000.00 | 727.57 |
>> 1068949964
>> (2 rows)
> Hmm, in this case it looks to me like you literally have two versions of
> the same row rather than two different rows with duplicate primary key
> values.
Yeah, given that the OIDs are the same, it seems certain that this is
the result of a partially applied UPDATE (ie, new row version committed,
old row version not deleted). In theory that can't happen ...
One way that it could happen is if you have a disk drive that lies about
write-complete (most IDE drives will do so out-of-the-box). If you had
a system crash shortly after the UPDATE in question, it could be that
Postgres thought the two parts of the update were both down to disk,
when in reality only one had made it to the platter.
regards, tom lane
