Re: strange failure in plpgsql_control tests (on fulmar, ICC 14.0.3) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: strange failure in plpgsql_control tests (on fulmar, ICC 14.0.3)
Date
Msg-id 13435.1521297168@sss.pgh.pa.us
Whole thread Raw
In response to strange failure in plpgsql_control tests (on fulmar, ICC 14.0.3)  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: strange failure in plpgsql_control tests (on fulmar, ICC 14.0.3)  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Re: strange failure in plpgsql_control tests (on fulmar, ICC 14.0.3)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> I happened to be updating our machine running our buildfarm animals, and
> I noticed something quite strange - the machine was unexpectedly running
> out of disk space, which is rather suspicious as it's running just the
> regression tests :-/

> After a bit of investigation, I found this:
> Right - the plpgsql_control.out output has about 58GB, which is somewhat
> excessive I guess. The reason is fairly simple:

>     NOTICE:  2147483620..2147483647 by 10: i = 2147483620
>     NOTICE:  2147483620..2147483647 by 10: i = 2147483630
>     NOTICE:  2147483620..2147483647 by 10: i = 2147483640
>     NOTICE:  2147483620..2147483647 by 10: i = -2147483646
>     NOTICE:  2147483620..2147483647 by 10: i = -2147483636
>     NOTICE:  2147483620..2147483647 by 10: i = -2147483626
>     ... many more NOTICE messages ...

> Looking at the plpgsql_call.out timestamp, this seems to be running
> since January 1, which also correlates with the last results reported to
> pgbuildfarm.

Ouch.  That test is in fact new as of 31 Dec, and what this seems to
prove is that plpgsql's handling of loop-variable overflow doesn't
work on fulmar.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: disable SSL compression?
Next
From: Tomas Vondra
Date:
Subject: Re: strange failure in plpgsql_control tests (on fulmar, ICC 14.0.3)