From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: check fails on Fedora 23 |
Date: | 2015-10-06 21:50:35 |
Message-ID: | 5614422B.5080506@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/06/2015 04:49 PM, Robert Haas wrote:
> On Sun, Oct 4, 2015 at 11:52 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>> Isn't this arguably a Fedora regression? What did they change in F23 to make
>> it fail? I note that F23 is still in Beta.
> Maybe, but it's pretty unfriendly for us to complain about a library
> issue, if it is one, by failing an Assert(). People with
> non-assert-enabled builds will just get wrong answers. Yuck.
>
> Thinking about how this could happen, I believe that one possibility
> is that there are two strings A and B and a locale L such that
> strcoll_l(A, B, L) and memcmp(strxfrm(A, L), strxfrm(B, L)) disagree
> (that is, the results are of different sign, or one is zero and the
> other is not).
>
> I don't have an environment handy to reproduce this, but it would be
> nifty if someone could figure out exactly what strings are failing and
> then provide the strcoll result and the strxfrm blobs for those
> strings.
Well, it's failing like this:
TRAP: FailedAssertion("!(compareResult < 0)", File:
"nodeMergejoin.c", Line: 942)
2015-10-04 20:03:42.894 UTC [56118614.53cf:2] LOG: server process
(PID 21681) was terminated by signal 6: Aborted
2015-10-04 20:03:42.894 UTC [56118614.53cf:3] DETAIL: Failed
process was running: SELECT p1.oid, p1.proname, p2.oid, p2.proname
FROM pg_proc AS p1, pg_proc AS p2
WHERE p1.oid < p2.oid AND
p1.prosrc = p2.prosrc AND
p1.prolang = 12 AND p2.prolang = 12 AND
(p1.proisagg = false OR p2.proisagg = false) AND
(p1.prolang != p2.prolang OR
p1.proisagg != p2.proisagg OR
p1.prosecdef != p2.prosecdef OR
p1.proleakproof != p2.proleakproof OR
p1.proisstrict != p2.proisstrict OR
p1.proretset != p2.proretset OR
p1.provolatile != p2.provolatile OR
p1.pronargs != p2.pronargs);
So I think the right way would be to do something like this:
for p1 in select * from pg_proc loop
for p2 in select * from pg_proc loop
raise notice 'p1: %, %, p2: % %', p1.proname, p1.prosrc,
p2,proname, p2,prosrc;
perform p1.prosrc = p2.prosrc;
end loop;
end loop;
Then the last notice raised should show us the offending strings at
least. Does that make sense?
Alternatively one could try to get it with a debugger.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-10-06 21:53:49 | Re: Odd query execution behavior with extended protocol |
Previous Message | Thomas Munro | 2015-10-06 21:45:34 | Re: check fails on Fedora 23 |