Re: propagating replica identity to partitions

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, 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-03-28 17:16:11
Message-ID: CANP8+jJn5Ws-pMN_n5U-8TCZSy9_2CQKT2UFSuswDHQ6C5Lu3A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 28 Mar 2019 at 16:46, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:

> Thanks, Michael and Peter, for responding; however there is a second
> part to the question, which is "should I change the recursivity of
> REPLICA IDENTITY, while not simultaneously changing the recusivity of
> the TABLESPACE and OWNER TO forms of ALTER TABLE?"
>
> I think everyone agrees that REPLICA IDENTITY should be changed.

+1

This is a metadata-only operation, so no problem.

> The
> question is whether it's bad behavior from my part to change it
> separately from changing every other non-currently-recursive form.
>

Changing OWNER is also just a metadata-only operation and makes sense to me
to recurse, by default.

SET TABLESPACE should not recurse because it copies the data, while holding
long locks. If that was ever fixed so it happened concurrently, I would
agree this could recurse by default.
IMHO this should be renamed to ALTER TABLE ... MOVE TO TABLESPACE, so its
actual effect is clearer.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2019-03-28 17:19:05 Re: Online verification of checksums
Previous Message Simon Riggs 2019-03-28 17:10:23 Re: propagating replica identity to partitions