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
