Re: pg_dump is broken for partition tablespaces

On Sat, 13 Apr 2019 at 11:36, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> Here's a patch to fix the reported problems. It's somewhat invasive,
> and I've spent a long time staring at it, so I very much appreciate eyes
> on it.

I think it's a bit strange that don't store the pg_default's oid in
reltablespace for objects other than partitioned tables and indexes.
For documents [1] say:

"When default_tablespace is set to anything but an empty string, it
supplies an implicit TABLESPACE clause for CREATE TABLE and CREATE
INDEX commands that do not have an explicit one."

I'd say the fact that we populate reltablespace with 0 is a bug as
it's not going to do what they want after a dump/restore.

If that's ok to change then maybe the attached is an okay fix. Rather
nicely it gets rid of the code that's commented with "Yes, this is a
bit of a hack." and also changes the contract with heap_create() so
that we just pass InvalidOid to mean use MyDatabaseTableSpace. I've
not really documented that in the patch yet. It also does not need
the pg_dump change to have it use ATTACH PARTITION instead of
PARTITION OF, although perhaps that's an okay change to make
regardless of this bug.

On Wed, 10 Apr 2019 at 10:58, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> There is one deficiency that needs to be solved in order for this to
> work fully: currently there is no way to reset "reltablespace" to 0.

Yeah, I noticed that too. My patch makes that a consistent problem
with all object types that allow tablespaces. Perhaps we can allow
ALTER ... <name> SET TABLESPACE DEFAULT; since "DEFAULT" is fully
reserved it can't be the name of a tablespace.

[1] https://www.postgresql.org/docs/devel/manage-ag-tablespaces.html

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services