postgres.git / summary / log / commit / refs

commit    47c43ffdae795e382903c63fd2169daa6b13be30
Author:   Tom Lane <tgl@sss.pgh.pa.us>
Date:     Fri Sep 18 15:02:10 2026 +0000

    Use default limitOption in subquery generated for MIN/MAX index scan.
    
    We unintentionally copied the original query's limitOption field while
    building the modified subquery.  If it was LIMIT_OPTION_WITH_TIES,
    that behavior would propagate through to execution, potentially
    causing a "more than one row returned by a subquery used as an
    expression" error.  Fix by resetting to the default LIMIT_OPTION_COUNT.
    This bug dates back to the introduction of WITH TIES.
    
    Bug: #19694
    Reported-by: Chaitanya Choudhary <chaitanyyachoudhary@gmail.com>
    Author: Chaitanya Choudhary <chaitanyyachoudhary@gmail.com>
    Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
    Discussion: https://postgr.es/m/19694-4e61bd0475398eef@postgresql.org
    Backpatch-through: 14


 src/backend/optimizer/plan/planagg.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/backend/optimizer/plan/planagg.c b/src/backend/optimizer/plan/planagg.c
index 9330908cbf1..597178d55d5 100644
--- a/src/backend/optimizer/plan/planagg.c
+++ b/src/backend/optimizer/plan/planagg.c
@@ -410,6 +410,7 @@ build_minmax_path(PlannerInfo *root, MinMaxAggInfo *mminfo,
 										   sizeof(int64),
 										   Int64GetDatum(1), false,
 										   FLOAT8PASSBYVAL);
+	parse->limitOption = LIMIT_OPTION_COUNT;
 
 	/*
 	 * Generate the best paths for this query, telling query_planner that we


[parent: 9b8c0f238952]