MDEV-25441 WITH TIES is not respected with SQL_BUFFER_RESULT and constant in ORDER BY

Pushing LIMIT to temp aggregation table is possible, but not when WITH
TIES is used. In a degenerate case with constant ORDER BY, the constant
gets removed and the code assumed the limit is push-able.

Ensure that if WITH TIES is present, that this does not happen.

mysql-test/main/fetch_first.result

@@ -1334,3 +1334,37 @@ a	b	sum(a)
 1	2	1
 1	3	1
 drop table t1;
+#
+# MDEV-25441
+# WITH TIES is not respected with SQL_BUFFER_RESULT and constant in ORDER BY
+#
+CREATE TABLE t1 (a INT);
+INSERT INTO t1 values (1), (2), (3), (4), (5), (6), (7), (8), (9), (10);
+explain SELECT SQL_BUFFER_RESULT 1 AS f FROM t1 ORDER BY f FETCH NEXT 2 ROW WITH TIES;
+id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
+1	SIMPLE	t1	ALL	NULL	NULL	NULL	NULL	10	Using temporary
+SELECT SQL_BUFFER_RESULT 1 AS f FROM t1 ORDER BY f FETCH NEXT 2 ROW WITH TIES;
+f
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+SELECT 1 AS f FROM t1 ORDER BY f FETCH NEXT 2 ROW WITH TIES;
+f
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
+drop table t1;

mysql-test/main/fetch_first.test

@@ -1028,6 +1028,17 @@ group by a, b
 order by (select 1), a
 fetch first 1 rows with ties;
 
+drop table t1;
+
+--echo #
+--echo # MDEV-25441
+--echo # WITH TIES is not respected with SQL_BUFFER_RESULT and constant in ORDER BY
+--echo #
+CREATE TABLE t1 (a INT);
+INSERT INTO t1 values (1), (2), (3), (4), (5), (6), (7), (8), (9), (10);
 
+explain SELECT SQL_BUFFER_RESULT 1 AS f FROM t1 ORDER BY f FETCH NEXT 2 ROW WITH TIES;
+SELECT SQL_BUFFER_RESULT 1 AS f FROM t1 ORDER BY f FETCH NEXT 2 ROW WITH TIES;
+SELECT 1 AS f FROM t1 ORDER BY f FETCH NEXT 2 ROW WITH TIES;
 
 drop table t1;

sql/sql_select.cc

@@ -3856,10 +3856,16 @@ JOIN::create_postjoin_aggr_table(JOIN_TAB *tab, List<Item> *table_fields,
     when there is ORDER BY or GROUP BY or there is no GROUP BY, but
     there are aggregate functions, because in all these cases we need
     all result rows.
+
+    We also can not push limit if the limit is WITH TIES, as we do not know
+    how many rows we will actually have. This can happen if ORDER BY was
+    a constant and removed (during remove_const), thus we have an "unlimited"
+    WITH TIES.
   */
   ha_rows table_rows_limit= ((order == NULL || skip_sort_order) &&
                               !table_group &&
-                              !select_lex->with_sum_func) ? select_limit
+                              !select_lex->with_sum_func &&
+                              !unit->lim.is_with_ties()) ? select_limit
                                                           : HA_POS_ERROR;
 
   if (!(tab->tmp_table_param= new TMP_TABLE_PARAM(tmp_table_param)))