On Thu, Nov 29, 2018 at 3:07 PM John Naylor <jcnaylor@gmail.com> wrote:
>
- * Copy/link any fsm and vm files, if they exist
+ *
Copy/link any fsm and vm files, if they exist and if they would
+ * be created in the
new cluster.
*/
- transfer_relfile(&maps[mapnum], "_fsm",
vm_must_add_frozenbit);
+ if (maps[mapnum].relkind != RELKIND_RELATION ||
+
first_seg_size > HEAP_FSM_CREATION_THRESHOLD * BLCKSZ ||
+
GET_MAJOR_VERSION(new_cluster.major_version) <= 1100)
+ (void) transfer_relfile
(&maps[mapnum], "_fsm", vm_must_add_frozenbit);
> During pg_upgrade, skip transfer of FSMs if they wouldn't have been created on the new cluster.
I think in some cases, it won't be consistent with HEAD's behavior.
After truncate, we leave the FSM as it is, so the case where before
upgrade the relation was truncated, we won't create the FSM in new
cluster and that will be inconsistent with the behavior of HEAD. I
think similar anomaly will be there when we delete rows from the table
such that after deletion size of relation becomes smaller than
HEAP_FSM_CREATION_THRESHOLD.
I am not sure if it is a good idea to *not* transfer FSM files during
upgrade unless we ensure that we remove FSM whenever the relation size
falls below HEAP_FSM_CREATION_THRESHOLD. What do you think? BTW,
what is your reasoning for not removing FSM on truncate?
Anybody else has an opinion on this matter?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com