Re: propagating replica identity to partitions

On Thu, 28 Mar 2019 at 16:46, Alvaro Herrera <alvherre@2ndquadrant.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/&gt;
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 2019-03-28 17:46, Alvaro Herrera 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. The
question is whether it's bad behavior from my part to change it
separately from changing every other non-currently-recursive form.

If this were new functionality, I would tend to think that ALTER TABLE
should by default recurse for everything. I don't know the history of
why it is not done for some things. It might be a mistake, just like
the replica identity case apparently is.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 2019-03-28 18:16, Simon Riggs wrote:

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.

Since a partitioned table has no storage, what is the meaning of moving
a partitioned table to a different tablespace without recursing?

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Fri, 29 Mar 2019 at 09:51, Peter Eisentraut <
peter.eisentraut@2ndquadrant.com> wrote:

On 2019-03-28 18:16, Simon Riggs wrote:

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.

Since a partitioned table has no storage, what is the meaning of moving
a partitioned table to a different tablespace without recursing?

My point was that people will misuse it and regret at length, but the data
copying behavior is clearly documented.

If you are saying there is no other possible interpretation of that
command, then I relent. It is important we have a way to do this, if people
wish it.

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

On 2019-Mar-29, Peter Eisentraut wrote:

On 2019-03-28 18:16, Simon Riggs wrote:

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.

Since a partitioned table has no storage, what is the meaning of moving
a partitioned table to a different tablespace without recursing?

Changing the tablespace of a partitioned table currently means to set a
default tablespace for partitions created after the change.

Robert proposed to change it so that it means to move every partition to
that tablespace, unless ONLY is specified. Simon objects to that change.

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services