So, in an attempt to see if it was a fluke, I picked one of the date ranges I was getting a different count for, and deleted the records, and then ran the insert again. Interestingly, the delete result matched the insert result (which was the same the second time as it was the first). I'll run a count on the records again, but it will take several hours. I'll post that information when I have it!
No triggers, no rules. It's just a very boring, vanilla table. I have had plenty of cases where the inserts fail because many of the data types are different in the new table, and there is some junk that fails the cast. And even though the insert result seems to indicate that it only inserted some of the rows, when I do a count of the records after the insert, I find the same number of records in the new as in the old table. So it
appears to be working correctly, but it's unsettling to see the insert result not match. Do I trust the count, or the insert result? Could this be a sign of some kind of corruption? Not sure how worried I should be.
Cheers,
Natalie
Natalie Wenz <nataliewenz@ebureau.com> writes:
I am moving some data from one table to another in 9.2.4, and keep seeing this strange scenario:
...
So, my counts from the old and new tables match, but the result returned from the insert statement is sometimes a completely different number. (But not always.) I've checked my date ranges very carefully to make sure they match.
Perhaps you've got triggers or rules on the target table that are
suppressing some inserts?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
