On Thu, Jan 28, 2021 at 10:56:29AM -0300, Alvaro Herrera wrote:
> Yep, seems OK to me, assuming that, as you say, you'll update the
> comments again when they are used to handle the concurrent cases.
That's the idea. I need first to look in depth at what's proposed on
the other thread for REINDEX
On 2021-Jan-28, Michael Paquier wrote:
> So, for now, I would just do the attached to address your
> suggestions. Is that fine for you?
Yep, seems OK to me, assuming that, as you say, you'll update the
comments again when they are used to handle the concurrent cases.
Thanks!
--
Álvaro Herrera
On Wed, Jan 27, 2021 at 11:07:41AM -0300, Alvaro Herrera wrote:
> Thanks, looks good. Small comment: CheckRelationTableSpaceMove is
> documented as
* newTableSpaceId is the new tablespace for the relation, and
- * newRelFileNode its new filenode. If newrelfilenode is InvalidOid,
+ * newRelFile
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 i
Refactor code in tablecmds.c to check and process tablespace moves
Two code paths of tablecmds.c (for relations with storage and without
storage) use the same logic to check if the move of a relation to a
new tablespace is allowed or not and to update pg_class.reltablespace
and pg_class.relfilenod
