Scott Marlowe wrote: > On Thu, 2006-07-06 at 16:36, Weerts, Jan wrote: >> Hi all! >> >> This was 8.1.3 and now is 8.1.4 running on Debian Sarge, locally >> compiled without any fancy options. > >> >> While the first answer seems much more valid (the primarkey is >> an artificially created number), the second answer seems to >> be the one being presented for all further invocations of the >> above query. >> >> I noted, that the second row does not fit the "order by" clause, >> so I tried a reindex of the db, but that led to a duplicate value >> error: # reindex index tw_blob_pkey; >> ERROR: could not create unique index >> DETAIL: Table contains duplicated values. >> >> Now that is something I don't understand at all. >> >> Since the backup for said server went postal too long ago >> unnoticed, I would prefer a "repair" solution. Any ideas? > > Can you get set of fields in that row to uniquely identify it by? > > If so, see if you can update that column to something else and > continue The only way would be to update by primarykey. But since the select on the primarykey field shows this "strange" ordering, I wonder, what effect an update would have. My guess would be, that the correct pk value should be 1636695, but seeing only 216305 on subsequent calls makes me think. I even have executed # select * from tw_blob where primarykey = 216305; and receive a single row, which I don't really trust to be the same one producing the error. Jan
