See the OD issue here
Basically if the Tomcat preparedStatementCache is used then AO can blow up on the second ao.migrate() after a destructive ALTER
The SD team is falling into this trap. Anyone how migrates multiple columns (in a standard migrate / copy / migrate) pattern will blow up with this.
It also seems to depend on what DB connection you get from the pool.
We need to "clean" out the connection / statement or change the way we do the meta data reading.
I noticed one thing about the code where is "re-uses" the metadata generating connection to get its statement. Maybe thats the problem?
Either way we need clean connections during migration on Postgres
The error from Postgres is
Notice the ao.migrate() call is trying to read the metadata having made a ALTERing DDL call and because the underlying database strcuture has change it blows up.
Setting the poolPreparedStatements="false" fixes the problem.