> company_nbr | company_name -------------+-------------------------------------------------
> 1 | Markowitz Herbold PC
> 2 | Markowitz Herbold PC
> 3 | Markowitz Herbold PC
> 4 | Markowitz Herbold PC
> 5 | Markowitz Herbold PC
> 6 | Markowitz Herbold PC
> 7 | Markowitz Herbold PC
> 8 | Markowitz Herbold PC
> 9 | Markowitz Herbold PC
> 10 | Markowitz Herbold PC
> 11 | Markowitz Herbold PC
> 12 | Markowitz Herbold PC
> 13 | Markowitz Herbold PC
> 14 | Markowitz Herbold PC
> 15 | Markowitz Herbold PC
> 16 | Markowitz Herbold PC
> 17 | Markowitz Herbold PC
> 18 | Markowitz Herbold PC
> 19 | Markowitz Herbold PC
> 20 | Markowitz Herbold PC
> 22 | Markowitz Herbold PC
> 23 | Markowitz Herbold PC
> --More--
Did those rows contain these values in some earlier transaction in your data-entry process perhaps? I’m thinking that
perhapsyou overwrote them in a later transaction with the correct values for the names, but forgot to commit that
transaction?
It’s either that, or you did run an UPDATE statement against those rows without specifying a WHERE-clause, as others
alreadysuggested as a likely cause.
I think we can rule out the possibility of index corruption (a very rare occurrence, usually caused by factors external
toPG) for your case. A data-set this limited would most likely result in an execution plan using a sequential scan
insteadof an index scan (an EXPLAIN ANALYZE of above select statement would show proof).
> It might be quicker for me to restore the entire database from that backup
> and then insert all new table rows since I have saved all the scripts.
If you end up in the same situation again after doing that, then you know at least it’s repeatable and can analyse how
yougot there.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll find there is no forest.