Re: strange failure in plpgsql_control tests (on fulmar, ICC 14.0.3)

Tomas Vondra <tomas.vondra@2ndquadrant.com>

From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2018-03-17T21:06:35Z
Lists: pgsql-hackers
On 03/17/2018 08:41 PM, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
>> On March 17, 2018 12:25:57 PM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> If we're not putting a test into the back branches, then we darn
>>> well better be using the same code there as in HEAD, else we
>>> won't know that it actually solves the problem.
> 
>> I was thinking of committing your version everywhere and then
>> revising in master after a bf cycle.
> 
> Meh.  I don't really feel a need to change it at all, but if we do,
> I think it should be "after a release cycle" not just a few days.
> We need to see whether that regression test will expose any problems
> on a wider variety of compilers than exist in the buildfarm.
> 
> Anyway, pushed for now --- Tomas, if you blocked fulmar, it should
> be safe to unblock.
> 

OK, enabled again. It'll take a while to run through the branches.

I guess it might want to notify people running affected animals, because
otherwise they may stay stuck for a long time.

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Commits

  1. Fix overflow handling in plpgsql's integer FOR loops.