Re: Native partitioning tablespace inheritance

From: Keith Fiske <keith(dot)fiske(at)crunchydata(dot)com>
To: "Jonathan S(dot) Katz" <jonathan(dot)katz(at)excoventures(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Christophe Pettus <xof(at)thebuild(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Native partitioning tablespace inheritance
Date: 2018-04-12 19:25:30
Message-ID: CAODZiv70rP42D2ZFpqKDcnwwvtE4_bhS54G4Ti9uUA0B8Of86g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 12, 2018 at 3:15 PM, Jonathan S. Katz <
jonathan(dot)katz(at)excoventures(dot)com> wrote:

>
> > On Apr 12, 2018, at 3:10 PM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
> wrote:
> >
> > Robert Haas wrote:
> >> On Thu, Apr 12, 2018 at 2:40 PM, Jonathan S. Katz
> >> <jonathan(dot)katz(at)excoventures(dot)com> wrote:
> >>> If there are no strong objections I am going to add this to the “Older
> Bugs”
> >>> section of Open Items in a little bit.
> >>
> >> I strongly object. This is not a bug. The TABLESPACE clause doing
> >> exactly what it was intended to do, which is determine where all of
> >> the storage associated with the partitioned table itself goes. It so
> >> happens that there is no storage, so now somebody would like to
> >> repurpose the same option to do something different. That's fine, but
> >> it doesn't make the current behavior wrong. And we're certainly not
> >> going to back-patch a behavior change like that.
>
> Behavior-wise it’s certainly a bug: you add a TABLESPACE on the parent
> table, and that property is not passed down to the children, which is not
> what the user expects. At a minimum, if we don’t back patch it, we
> probably
> need to update the documentation to let people know.
>
> > Keep in mind that we do not offer any promises to fix items listed in
> > the Older Bugs section; as I said elsewhere, it's mostly a dumping
> > ground for things that get ignored later. I think it's fine to add it
> > there, if Jon wants to keep track of it, on the agreement that it will
> > probably not lead to a backpatched fix.
>
> Per an off-list discussion, it does not make sense to back patch but
> it does make sense to try to get it into 11 as part of making things more
> stable.
>
> Perhaps as a short-term fix, we update the docs to let users know that if
> you put a TABLESPACE on the parent table it does not get passed down
> to the children?
>
> Jonathan
>
>

I also think it's rather confusing that, even though there is technically
no data storage going on with the parent, that the parent itself does not
get placed in the tablespace given to the creation command. Just completely
ignoring a flag given to a command with zero feedback is my biggest
complaint on this. If it's going to be ignored, at least giving some sort
of feedback (kind of like long name truncation does) would be useful here
and should be considered for back-patching to 10.
--
Keith Fiske
Senior Database Engineer
Crunchy Data - http://crunchydata.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-04-12 19:33:02 Re: submake-errcodes
Previous Message Peter Marreck 2018-04-12 19:25:22 Proposal: Remove "no" from the default english.stop word list