@@ -1033,14 +1033,15 @@ RecordTransactionCommit(void)
10331033 * Check if we want to commit asynchronously. We can allow the XLOG flush
10341034 * to happen asynchronously if synchronous_commit=off, or if the current
10351035 * transaction has not performed any WAL-logged operation. The latter case
1036- * can arise if the current transaction wrote only to temporary tables.
1037- * In case of a crash, the loss of such a transaction will be irrelevant
1038- * since temp tables will be lost anyway. (Given the foregoing, you might
1039- * think that it would be unnecessary to emit the XLOG record at all in
1040- * this case, but we don't currently try to do that. It would certainly
1041- * cause problems at least in Hot Standby mode, where the KnownAssignedXids
1042- * machinery requires tracking every XID assignment. It might be OK to
1043- * skip it only when wal_level < hot_standby, but for now we don't.)
1036+ * can arise if the current transaction wrote only to temporary and/or
1037+ * unlogged tables. In case of a crash, the loss of such a transaction
1038+ * will be irrelevant since temp tables will be lost anyway, and unlogged
1039+ * tables will be truncated. (Given the foregoing, you might think that it
1040+ * would be unnecessary to emit the XLOG record at all in this case, but we
1041+ * don't currently try to do that. It would certainly cause problems at
1042+ * least in Hot Standby mode, where the KnownAssignedXids machinery
1043+ * requires tracking every XID assignment. It might be OK to skip it only
1044+ * when wal_level < hot_standby, but for now we don't.)
10441045 *
10451046 * However, if we're doing cleanup of any non-temp rels or committing any
10461047 * command that wanted to force sync commit, then we must flush XLOG