On 10/06/2015 04:49 PM, Robert Haas wrote:
On Sun, Oct 4, 2015 at 11:52 AM, Andrew Dunstan <and...@dunslane.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
