Re: propagating replica identity to partitions

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: propagating replica identity to partitions
Date: 2019-02-20 18:31:25
Message-ID: CANP8+jJMhtcxmEirDLMmy+-3kE_QcK6LWqBt2LYoeS-TyZqvGg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 20 Feb 2019 at 17:38, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:

> > Fair enough. I don't think it's entirely useful to think about this
> > in terms of which operations do and don't recurse; the question in my
> > mind is WHY some things recurse and other things don't, and what will
> > be easiest for users to understand.
>
> I think the reason tablespace was made not to recurse was to avoid
> acquiring access exclusive lock on too many tables at once, but I'm not
> sure. This is very old behavior.
>

-1 for changing that; here's why:

Partitioning is designed to support very large tables.

Since the table is very large there is a valid use case for moving older
partitions to other tablespaces, one at a time.

If we moved all partitions at once, while holding AccessExclusiveLock, it
would a) likely fail with out of space errors, b) if you are unlucky enough
for it to succeed it would lock the table for a ridiculously long time. The
main use case for changing the tablespace is to define where new partitions
should be created. So in this specific case only, recursion makes no sense.

> > Obviously any property where the
> > parents and children have to match, like adding a column or changing a
> > data type, has to always recurse; nothing else is sensible. For
> > others, it seems we have a choice. It's unclear to me why we'd choose
> > to make REPLICA IDENTITY recurse by default and, say, OWNER not
> > recurse.
>
> Ah. I did argue that OWNER should recurse:
> https://postgr.es/m/20171017163203.uw7hmlqonidlfeqj@alvherre.pgsql
> but it was too late then to change it for pg10. We can change it now,
> surely.
>
> > In both cases, the default assumption is presumably that the
> > whole partitioning hierarchy should match, but in a particular case a
> > user could want to do something else. Consequently, I don't
> > understand why a user would want one of those operations to descend to
> > children by default and the other not.
>
> I agree that OWNER TO should recurse for partitioned tables.

+1

That was clearly just missed. It's a strange thought to have a partitioned
table with different pieces owned by different users. So strange that the
lack of complaints about the recursion are surely because nobody ever tried
it in a real situation. I would prefer to disallow differences in ownership
across partitions, since that almost certainly prevents running sensible
DDL and its just a huge footgun.

Recursion should be the default for partitioned tables.

I'm -0 on
> changing it for legacy inheritance, but if the majority is to change it
> for both, let's do that.
>

-1 for changing legacy inheritance. Two separate features. Inheritance has
been around for many years and its feature set is stable. No need to touch
it.

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2019-02-20 18:37:40 Re: Compressed TOAST Slicing
Previous Message Robert Haas 2019-02-20 18:15:57 Re: Compressed TOAST Slicing