Whether to back-patch fix for aggregate transtype width estimates - Mailing list pgsql-hackers

From Tom Lane
Subject Whether to back-patch fix for aggregate transtype width estimates
Date
Msg-id 6221.1466217713@sss.pgh.pa.us
Whole thread Raw
Responses Re: Whether to back-patch fix for aggregate transtype width estimates
List pgsql-hackers
While fixing the recent unpleasantness over parallel polymorphic
aggregates, I discovered that count_agg_clauses_walker's consideration
of an aggregate argument's typmod in estimating transition space
consumption has been broken since commit 34d26872e (which changed
Aggref.args from a simple expression list to a list of TargetEntry).
It had been looking at "exprTypmod((Node *) linitial(aggref->args))",
and nobody taught it that there was now a TargetEntry in the way that
it needed to look through to get a correct answer.

Ordinarily I'd just summarily back-patch a fix, but that commit shipped
in 9.0, which means it's been broken a long time.  I'm worried that
back-patching a change might be more likely to destabilize plan choices
than to do anything anybody's happy about.

Thoughts?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: MultiXactId error after upgrade to 9.3.4
Next
From: Thomas Munro
Date:
Subject: Assert(LWLockHeldByMeInMode(lock, LW_EXCLUSIVE))