Incorporate feedback from Support

Author: kbatuigas

modules/develop/pages/transactions.adoc

@@ -270,7 +270,7 @@ Redpanda’s default configuration supports exactly-once processing. To preserve
 
 To help avoid common pitfalls and optimize performance, consider the following when configuring transactional workloads in Redpanda:
 
-* If a consumer is configured to process only messages from successfully committed transactions, an ongoing transaction with a large timeout that becomes stuck might block consumers from processing more committed transactions. This prevents consumers from advancing their offsets and potentially causes backlogs.
+* If a consumer is configured to use the read_committed isolation level, it can only process successfully committed transactions. As a result, an ongoing transaction with a large timeout that becomes stuck could prevent the consumer from processing other committed transactions.
 +
 To avoid this, don't set the transaction timeout client setting (`transaction.timeout.ms` in the Kafka Java client implementation) to a value that is too high. The longer the timeout, the longer consumers may be blocked. 
 ifndef::env-cloud[]

modules/manage/pages/cluster-maintenance/disk-utilization.adoc

@@ -165,21 +165,21 @@ Redpanda supports group offset deletion with the Kafka OffsetDelete API through
 
 == Manage transaction coordinator disk usage
 
-Redpanda uses the internal topic `kafka_internal/tx` to store transaction metadata for exactly-once and transactional producers. Over time, this topic can consume excessive disk space in niche use cases that generate a large number of transactional sessions.
+Redpanda uses the internal topic `kafka_internal/tx` to store transaction metadata for exactly-once and transactional producers. The log files contain all historical transactions, both committed and current open ones. Over time, this topic can consume excessive disk space in niche use cases that generate a large number of transactional sessions.
 
 You can manage the disk usage of `kafka_internal/tx` by tuning the following cluster properties:
 
 * config_ref:transaction_coordinator_delete_retention_ms,true,properties/cluster-properties[`transaction_coordinator_delete_retention_ms`]. Default: `604800000` (7 days).
 * config_ref:transactional_id_expiration_ms,true,properties/cluster-properties[`transactional_id_expiration_ms`]. Default: `604800000` (7 days).
 
-To mitigate unbounded growth of `kafka_internal/tx` disk usage and manage its storage consumption more effectively, <<monitor-disk-space,monitor your storage metrics>> and lower the values of the relevant properties as needed. 
+To mitigate unbounded growth of `kafka_internal/tx` disk usage and manage its storage consumption more effectively, <<monitor-disk-space,monitor your storage metrics>> and lower the values of the relevant properties as needed.
 
 To adjust these properties, run:
 
 [,bash]
 ----
 rpk cluster config set transaction_coordinator_delete_retention_ms=<milliseconds> transactional_id_expiration_ms=<milliseconds>
----- 
+----
 
 == Configure segment size
 

modules/reference/pages/properties/cluster-properties.adoc

@@ -6259,7 +6259,9 @@ Cleanup policy for a transaction coordinator topic.
 
 === transaction_coordinator_delete_retention_ms
 
-Delete segments older than this age. To ensure transaction state is retained as long as the longest-running transaction, make sure this is no less than <<transactional_id_expiration_ms,`transactional_id_expiration_ms`>>.
+Delete segments older than this age. To ensure transaction state is retained for as long as the longest-running transaction, make sure this is greater than or equal to <<transactional_id_expiration_ms,`transactional_id_expiration_ms`>>.
+
+For example, if your typical transactions run for one hour, consider setting both `transaction_coordinator_delete_retention_ms` and `transactional_id_expiration_ms` to at least 3600000 (one hour), or a little over.
 
 *Unit:* milliseconds