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!
On Jul 22, 2013, at 10:44 AM, Natalie Wenz <nataliew...@ebureau.com> wrote: > 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 > > > On Jul 19, 2013, at 6:14 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> Natalie Wenz <nataliew...@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 >
