Re: Duplicate primary key record

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
Cc: Joel Jacobson <joel(at)jacobson(dot)be>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Duplicate primary key record
Date: 2003-11-16 18:54:11
Message-ID: 29610.1069008851@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Gaetano Mendola 2003-11-17 23:36:05 Other Contributors List
Previous Message Gaetano Mendola 2003-11-16 18:42:23 Re: Duplicate primary key record