Do DELETE instead of TRUNCATE when locks aren't acquired

After compression, the uncompressed part of the chunk is truncated.
This requires upgrading the `ExclusiveLock` to an
`AccessExclusiveLock` and hence is sometimes blocked by other other
operations, including reads, on the chunk. This leads to longer
compress times or potential deadlocks.

Instead of this, we fall back to deleting the tuples in the chunk
row-by-row when the upgraded lock isn't immediately acquired.

.unreleased/pr_7785

@@ -0,0 +1 @@
+Implements: #7785 Do DELETE instead of TRUNCATE when locks aren't acquired

tsl/src/compression/compression.c

@@ -505,7 +505,15 @@ compress_chunk(Oid in_table, Oid out_table, int insert_options)
 	if (!ts_guc_enable_delete_after_compression)
 	{
 		DEBUG_WAITPOINT("compression_done_before_truncate_uncompressed");
-		truncate_relation(in_table);
+		if (ConditionalLockRelation(in_rel, AccessExclusiveLock))
+		{
+			truncate_relation(in_table);
+		}
+		else
+		{
+			/* Instead of waiting, delete rows one-by-one */
+			delete_relation_rows(in_table);
+		}
 		DEBUG_WAITPOINT("compression_done_after_truncate_uncompressed");
 	}
 	else