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
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 |