On Mon, Mar 19, 2018 at 10:32 AM, Thomas Munro
wrote:
> On Sun, Mar 18, 2018 at 7:33 AM, Andres Freund wrote:
>> On 2018-03-17 14:20:26 -0400, Tom Lane wrote:
>>> It might be worth studying the icc manual to see if it has an
>>> equivalent of -fwrapv.
>>
>> Yes.
>>
>> A *quick* look through https
On Sun, Mar 18, 2018 at 7:33 AM, Andres Freund wrote:
> On 2018-03-17 14:20:26 -0400, Tom Lane wrote:
>> It might be worth studying the icc manual to see if it has an
>> equivalent of -fwrapv.
>
> Yes.
>
> A *quick* look through https://software.intel.com/en-us/node/522795
> unfortunately didn't s
Tomas Vondra writes:
> I guess it might want to notify people running affected animals, because
> otherwise they may stay stuck for a long time.
Yeah, I sent something out to buildfarm-members already.
regards, tom lane
On 03/17/2018 08:41 PM, Tom Lane wrote:
> Andres Freund writes:
>> On March 17, 2018 12:25:57 PM PDT, Tom Lane 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 pr
Andres Freund writes:
> On March 17, 2018 12:25:57 PM PDT, Tom Lane 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 ve
On March 17, 2018 12:25:57 PM PDT, Tom Lane wrote:
>Andres Freund writes:
>> I don't think performance is a prime driver here, or shouldn't be at
>least. Obviousness / grepability seem much more important. I'd vote
>for using my version in master, and yours in the back branches. I can
>do tha
Andres Freund writes:
> I don't think performance is a prime driver here, or shouldn't be at least.
> Obviousness / grepability seem much more important. I'd vote for using my
> version in master, and yours in the back branches. I can do that, of you
> want.
I dunno, I think the code as I ha
On March 17, 2018 11:32:36 AM PDT, Tom Lane wrote:
>Andres Freund writes:
>> On the current branch just using the new overflow safe functions in
>> int.h should work. But unless we are OK leaving this broken in the
>back
>> branches, or want to backport the functionality, that's probably not
>>
On 03/17/2018 07:20 PM, Tom Lane wrote:
> Tomas Vondra writes:
>> Not sure, but the backbranches seem to be working fine, and the commit
>> that triggers the issue is from December 31. Maybe the issue was there
>> but we were lucky not to trip on it before.
>
> Yeah, we were simply not testing
Hi,
On 2018-03-17 14:20:26 -0400, Tom Lane wrote:
> It might be worth studying the icc manual to see if it has an
> equivalent of -fwrapv.
Yes.
A *quick* look through https://software.intel.com/en-us/node/522795
unfortunately didn't show anything.
> Although we can and probably should fix this
Andres Freund writes:
> On the current branch just using the new overflow safe functions in
> int.h should work. But unless we are OK leaving this broken in the back
> branches, or want to backport the functionality, that's probably not
> sufficient.
Yeah ... I don't like either of the last two t
Tomas Vondra writes:
> Not sure, but the backbranches seem to be working fine, and the commit
> that triggers the issue is from December 31. Maybe the issue was there
> but we were lucky not to trip on it before.
Yeah, we were simply not testing that overflow-detection code before.
Undoubtedly it
Hi,
On 2018-03-17 18:55:11 +0100, Tomas Vondra wrote:
> Not sure, but the backbranches seem to be working fine, and the commit
> that triggers the issue is from December 31.
Well, that added the test. Are you saying that if you execute similar
code on an older branch it doesn't fail?
> Anyway,
On 03/17/2018 06:27 PM, Andres Freund wrote:
>
>
> On March 17, 2018 7:56:40 AM PDT, Tom Lane wrote:
>> I wrote:
>>> 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.
>>
>> Some of the
On March 17, 2018 7:56:40 AM PDT, Tom Lane wrote:
>I wrote:
>> 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.
>
>Some of the other icc-using critters haven't reported in since
>December
I wrote:
> 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.
Some of the other icc-using critters haven't reported in since
December, either :-(
Looking at the code, we do this like so:
On 03/17/2018 03:32 PM, Tom Lane wrote:
> Tomas Vondra 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
>> regr
Tomas Vondra 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
18 matches
Mail list logo
