Set NONCONTIGUOUS status flag upon OSM chunk creation

src/chunk.c

@@ -4614,10 +4614,17 @@ add_foreign_table_as_chunk(Oid relid, Hypertable *parent_ht)
 	chunk_add_inheritance(chunk, parent_ht);
 	/*
 	 * Update hypertable entry with tiering status information.
-	 * Noncontiguous flag is not set since the chunk is empty upon creation,
-	 * with an invalid range assigned, so ordered append should be allowed.
+	 * XXX: For compatibility reasons, we set the noncontiguous flag, but
+	 * this should be reverted as soon as the newer version of the OSM extension
+	 * is rolled out.
+	 * Noncontiguous flag should not be set since the chunk should be empty upon
+	 * creation, with an invalid range assigned, so ordered append should be allowed.
+	 * Once the data is moved into the OSM chunk, then our catalog should be
+	 * udpated with proper API calls from the OSM extension.
 	 */
-	parent_ht->fd.status = ts_set_flags_32(parent_ht->fd.status, HYPERTABLE_STATUS_OSM);
+	parent_ht->fd.status =
+		ts_set_flags_32(parent_ht->fd.status,
+						HYPERTABLE_STATUS_OSM | HYPERTABLE_STATUS_OSM_CHUNK_NONCONTIGUOUS);
 	ts_hypertable_update(parent_ht);
 }
 

tsl/test/expected/chunk_utils_internal.out

@@ -526,9 +526,14 @@ SELECT _timescaledb_functions.attach_osm_table_chunk('ht_try', 'child_fdw_table'
  t
 (1 row)
 
--- must also update the range since the created chunk is assumed to be empty,
--- and its range actually updated when data is moved to OSM. But in this mock
--- test case, the attached OSM chunk contains data
+-- check hypertable status
+SELECT status FROM _timescaledb_catalog.hypertable WHERE table_name = 'ht_try';
+ status 
+--------
+      3
+(1 row)
+
+-- must also update the range since the created chunk contains data
 SELECT _timescaledb_functions.hypertable_osm_range_update('ht_try', '2020-01-01'::timestamptz, '2020-01-02');
  hypertable_osm_range_update 
 -----------------------------

tsl/test/sql/chunk_utils_internal.sql

@@ -332,9 +332,9 @@ SELECT _timescaledb_functions.hypertable_osm_range_update('ht_try','2020-01-01 0
 \set ON_ERROR_STOP 1
 
 SELECT _timescaledb_functions.attach_osm_table_chunk('ht_try', 'child_fdw_table');
--- must also update the range since the created chunk is assumed to be empty,
--- and its range actually updated when data is moved to OSM. But in this mock
--- test case, the attached OSM chunk contains data
+-- check hypertable status
+SELECT status FROM _timescaledb_catalog.hypertable WHERE table_name = 'ht_try';
+-- must also update the range since the created chunk contains data
 SELECT _timescaledb_functions.hypertable_osm_range_update('ht_try', '2020-01-01'::timestamptz, '2020-01-02');
 
 -- OSM chunk is not visible in chunks view