On 2019-Jun-07, Alvaro Herrera wrote: > I looked for other cases that could have been broken by changing the > partition creation methodology in pg_dump, and didn't find anything. > That part of pg_dump (dumpTableSchema) is pretty spaghettish, though; > the fact that shouldPrintColumn makes some partitioned-related decisions > and then dumpTableSchema make them again is notoriously confusing. I > could have easily missed something.
There was indeed one more problem, that only the pg10 pg_upgrade test detected. Namely, binary-upgrade dump didn't restore for locally defined constraints: they were dumped twice, first in the table definition and later by the ALTER TABLE ADD CONSTRAINT bit for binary upgrade that I had failed to notice. Ooops. The reason pg10 detected it and the other branches didn't, is that the only constraint of this ilk that remained after running regress was removed by 05bd889904e0 :-( Pushed to the three branches. Hopefully it won't explode as spectacularly this time ... -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
