From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrey Rachitskiy <pl0h0yp1@gmail.com>
cc: feasiblechart@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #19615: COVAR_POP / COVAR_SAMP / REGR_SXY return 0.0 instead
 of NaN
In-reply-to: 
 <CAB8bMiu6BYW2TfQPaVs759e+Sf6UpZ_Ag60TfuDi57npfcY-yg@mail.gmail.com>
References: <19615-c7e390593416f6b6@postgresql.org>
 <CAB8bMiu6BYW2TfQPaVs759e+Sf6UpZ_Ag60TfuDi57npfcY-yg@mail.gmail.com>
Comments: In-reply-to Andrey Rachitskiy <pl0h0yp1@gmail.com>
	message dated "Tue, 11 Aug 2026 20:24:19 +0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2395188.1786463799.1@sss.pgh.pa.us>
Date: Tue, 11 Aug 2026 11:56:39 -0400
Message-ID: <2395189.1786463799@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2395189.1786463799%40sss.pgh.pa.us>
Precedence: bulk

Andrey Rachitskiy <pl0h0yp1@gmail.com> writes:
> With a constant X and Inf arriving later in Y, commonX stays finite,
> so that update is skipped and Sxy remains 0.  Before the commit, Sxy
> was always updated.  With constant X, tmpX is ~0, so the product
> 0*Inf (or a tiny roundoff times Inf) produced NaN under IEEE rules.
> Inf in the first row still yields NaN, because the older first-input
> path from 33dd9bb3b0a is intact and forces Sxy to NaN up front.
> The new short-circuit never got the matching Inf/NaN handling.

Yeah, I just arrived at pretty much the same conclusion.  We get
Inf/NaN handling right for Sxx and Syy, but not for the cross-product
Sxy.

			regards, tom lane