From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pgsql: Refactor code in tablecmds.c to check and process tablespace mov |
Date: | 2021-01-27 14:07:41 |
Message-ID: | 20210127140741.GA14174@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
On 2021-Jan-27, Michael Paquier wrote:
> Refactor code in tablecmds.c to check and process tablespace moves
Thanks, looks good. Small comment: CheckRelationTableSpaceMove is
documented as
+ * Returns true if the relation can be moved to the new tablespace;
+ * false otherwise.
but in reality it returns false if the relation does not *need* to be
moved because the tablespace is the same as before. In the cases where
it "cannot" be moved, what it does is raise an error.
Maybe this needs is just be documented more clearly:
"Returns true if the relation can be moved to the new tablespace; raises
an error if it is not possible to do the move; returns false if the move
would have no effect."
For cases of relation with storage, I find it suspicious that the
functions are documented to be fine with just ShareUpdateExclusiveLock.
I think it'd be safer for the comment to explicitly indicate that for
relations with storage, lock should be AEL.
--
Álvaro Herrera 39°49'30"S 73°17'W
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2021-01-27 17:24:05 | pgsql: Move StartupCLOG() calls to just after we initialize ShmemVariab |
Previous Message | Peter Geoghegan | 2021-01-27 07:26:09 | pgsql: Fix GiST index deletion assert issue. |