This is typical of a common design / implementation flaw - that is treatng Netezza like a transactional database. Netezza is not a transactional database in any sense of the word or concept. It will not behave with the same concurrency as say Oracle, and single-row inserts are extremely inefficient and are to be avoided completely in bulk data processing.

Are you certain that no updates or deletes are happening on this table? This type of error typically happens when more than one thread is addressing a table in an inconsistent manner (one doing an insert while another is doing an update etc)  Check out the concurrency rules for a transactional session - if you are doing anything to the tables (e.g truncate or select on the inserted data) inside the stored proc, it will throw an error.

As a practice, whenever we perform an insert, we should not go back to count the records in the target table. If an error occurs, something else is wrong. But if an error does not occur, we have no reason to believe that the records didn't insert. It is therefore better to derive our count, if that's what we're really after, from the incoming data rather than the target table. Think about what this actually means. It's the equivalent of throwing a truckload of fish into a lake, then going back into the lake to count the fish. In all of data warehouseing, it is better to count the fish while they are still in the truck.

If we are performing multiple mini-inserts, this is also problematic. Netezza is not efficient with single row or small-count inserts, so it is better to bundle up smaller counts into a larger critcal mass. If we are doing single-row inserts for job control tables and the like, it's still just as inefficient, but it's usually not as frequent if we are collecting smaller data sets into larger ones.

tricks and tips for how to navigate these issues (as a practice) are found in Netezza Underground. (Amazon.com)