Re: tadarida vs REL_12_STABLE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Tom Turelinckx" <pgbf(at)twiska(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: tadarida vs REL_12_STABLE
Date: 2020-04-16 00:40:28
Message-ID: 3382.1586997628@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Tom Turelinckx" <pgbf(at)twiska(dot)com> writes:
> It turns out I'd missed one failure:
> https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=tadarida&br=REL_12_STABLE
> Only tadarida fails the sequence regression test, and only
> for REL_12_STABLE. It fails with -O2 and -O1 but succeeds with -O0.

Yeah, I saw that. The failure mode is really pretty odd:

CREATE SEQUENCE sequence_test9 AS integer INCREMENT BY -1;
+ERROR: MINVALUE (-9223372036854775808) is out of range for sequence data type integer

It's not difficult to see where things must be going wrong: sequence.c,
around line 1490 in HEAD, must be choosing to set the sequence's seqmin
to PG_INT64_MIN instead of PG_INT32_MIN as it should. But that code is
exactly the same from HEAD back to v11 (and probably further, though
I didn't look).

The next two failures are the same thing for smallint, and the rest is
just fallout from the sequence-creation failures. So that's one extremely
specific codegen bug in the whole test suite. I wonder if it's related to
the branch-delay-slot codegen bug we identified for sparc32 awhile back.

Not sure what to tell you, other than that it's darn odd that this only
fails in v12. But I don't have much faith that "use -O0 in v12 only"
is going to be a long-term answer.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2020-04-16 01:11:40 Re: xid wraparound danger due to INDEX_CLEANUP false
Previous Message Robert Haas 2020-04-15 23:57:45 Re: xid wraparound danger due to INDEX_CLEANUP false