Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Rushabh Lathia <rushabh.lathia@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-06-13T00:46:57Z
Lists: pgsql-hackers 
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?
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.

			regards, tom lane

Commits

  1. Make pg_dump emit ATTACH PARTITION instead of PARTITION OF (reprise)

  2. Revert "Make pg_dump emit ATTACH PARTITION instead of PARTITION OF"

  3. Make pg_dump emit ATTACH PARTITION instead of PARTITION OF

  4. Allow a partitioned table to have a default partition.

  5. Give partitioned table "p" in regression tests a less generic name.