Search Postgresql Archives

Re: Duplicate primary keys/rows

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I don't have a compiler on this machine. If somebody
can point me to a copy of pg_filedump for Windows (I
didn't see any using Google) I'd be happy to use it.
Or perhaps I could compile it under cygwin.

The hard drive is a Western Digital 200GB JD (SATA),
if that can be used to determine how badly it lies. ;)

Thanks,
CSN


--- Tom Lane <tgl@xxxxxxxxxxxxx> wrote:

> CSN <cool_screen_name90001@xxxxxxxxx> writes:
> >   oid   |   ctid    |  xmin   | cmin |  xmax   |
> cmax | id
> >
>
--------+-----------+---------+------+---------+------+-----
> >  125466 | (2672,11) | 1445346 |    0 | 1481020 |  
>  0 | 985
> >  125466 | (2745,50) | 1481020 |    0 | 1682425 |  
>  2 | 985
> 
> Hmm.  The fact that the dup rows have the same OID
> indicates pretty
> strongly that they are actually two versions of the
> same row, and
> not two independently inserted rows.  Furthermore we
> can see that xact 
> 1481020 deleted the first version and inserted the
> second (note I took
> the liberty of rearranging your output to make the
> rows appear in
> chronological order).
> 
> So the index hasn't screwed up, exactly; the problem
> is that both rows
> appear as good at the same time.  But why?
> 
> It's really highly annoying that we can't see the
> contents of the
> infomasks for the rows.  Would you be willing to
> grab a copy of
> pg_filedump and dump out these two data pages so we
> can see the
> complete tuple headers?
> 
> (If you don't have a compiler then you'd need to
> find a precompiled
> copy of pg_filedump for Windows.  I don't know if
> anyone's made one
> available.)
> 
> Given that you say the machine has been crashing, my
> bet is that a crash
> caused the loss of pg_clog status for xid 1481020 at
> a time when
> 2745,50's xmin had been marked committed good, but
> 2672,11's xmax had
> not been similarly marked.  We have sufficient
> defenses against this
> sort of thing *if the disk drive does not lie about
> write complete*.
> (Unfortunately the vast majority of el-cheapo PCs
> are configured to lie
> with abandon, which means that we can't guarantee
> data consistency
> across power failures on such hardware.)  It'd be
> nice to get direct
> confirmation of that theory though.
> 
> 			regards, tom lane
> 



		
__________________________________ 
Yahoo! Music Unlimited 
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

               http://archives.postgresql.org

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux