On 2019-Jun-12, Tom Lane wrote: > Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > > 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 :-( > > Seems like we'd better put back some coverage for that case, no?
I'll work on that. > But I'm confused by your reference to 05bd889904e0. It looks like > that didn't change anything about tables that weren't getting dropped > anyhow. Ah ... yeah, I pasted the wrong commit ID. That commit indeed removed one occurrence of constraint check_b, but it wasn't the one that detected the failure -- the one that did (also named check_b) was removed by commit 6f6b99d1335b (pg11 only). Commit aa56671836e6 (in pg10, two months after 05bd889904e0) changed those tables afterwards so that they wouldn't be dropped. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
