Re: pg_dump: fail to restore partition table with serial type

On 2019-Jun-12, Tom Lane wrote:

> Alvaro Herrera <alvherre(at)2ndquadrant(dot)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