On 2019-Jun-12, Tom Lane wrote:
> Alvaro Herrera <alvherre@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