Re: check fails on Fedora 23

2015-10-04 10:50 GMT+02:00 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:

> Hi
>
> I am testing PostgreSQL (master) on Fedora 23. The query
>
> ELECT 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);
>
> fails on assert
>
> Program terminated with signal SIGABRT, Aborted.
> #0 0x00007f3e1dfe5a98 in __GI_raise (sig=sig(at)entry=6) at
> ../sysdeps/unix/sysv/linux/raise.c:55
> 55 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
> (gdb) bt
> #0 0x00007f3e1dfe5a98 in __GI_raise (sig=sig(at)entry=6) at
> ../sysdeps/unix/sysv/linux/raise.c:55
> #1 0x00007f3e1dfe769a in __GI_abort () at abort.c:89
> #2 0x00000000007c5401 in ExceptionalCondition
> (conditionName=conditionName(at)entry=0x935157 "!(compareResult < 0)",
> errorType=errorType(at)entry=0x802217 "FailedAssertion",
> fileName=fileName(at)entry=0x935147 "nodeMergejoin.c",
> lineNumber=lineNumber(at)entry=942) at assert.c:54
> #3 0x00000000005eba9f in ExecMergeJoin (node=node(at)entry=0x175f120) at
> nodeMergejoin.c:942
> #4 0x00000000005d3958 in ExecProcNode (node=node(at)entry=0x175f120) at
> execProcnode.c:480
> #5 0x00000000005cfe87 in ExecutePlan (dest=0x177d1e0,
> direction=<optimized out>, numberTuples=0, sendTuples=<optimized out>,
> operation=CMD_SELECT, planstate=0x175f120, estate=0x175f008) at
> execMain.c:1562
> #6 standard_ExecutorRun (queryDesc=0x16c7e88, direction=<optimized out>,
> count=0) at execMain.c:342
> #7 0x00000000006dd038 in PortalRunSelect (portal=portal(at)entry=0x16bed38,
> forward=forward(at)entry=1 '\001', count=0,
> count(at)entry=9223372036854775807, dest=dest(at)entry=0x177d1e0) at
> pquery.c:942
> #8 0x00000000006de57e in PortalRun (portal=portal(at)entry=0x16bed38,
> count=count(at)entry=9223372036854775807,
> isTopLevel=isTopLevel(at)entry=1 '\001', dest=dest(at)entry=0x177d1e0,
> altdest=altdest(at)entry=0x177d1e0,
> completionTag=completionTag(at)entry=0x7ffe4f8236f0 "") at pquery.c:786
> #9 0x00000000006db29b in exec_simple_query (
> query_string=0x1715318 "SELECT p1.oid, p1.proname, p2.oid,
> p2.proname\nFROM pg_proc AS p1, pg_proc AS p2\nWHERE p1.oid < p2.oid
> AND\n p1.prosrc = p2.prosrc AND\n p1.prolang = 12 AND p2.prolang = 12
> AND\n (p1.proisagg = f"...) at postgres.c:1105
> #10 PostgresMain (argc=<optimized out>, argv=argv(at)entry=0x16a57a0,
> dbname=0x16a5500 "regression", username=<optimized out>)
> at postgres.c:4033
> #11 0x000000000046810f in BackendRun (port=0x16c5f50) at postmaster.c:4204
> #12 BackendStartup (port=0x16c5f50) at postmaster.c:3880
> #13 ServerLoop () at postmaster.c:1683
> #14 0x000000000067e98b in PostmasterMain (argc=argc(at)entry=8,
> argv=argv(at)entry=0x16a45e0) at postmaster.c:1292
> #15 0x0000000000469376 in main (argc=8, argv=0x16a45e0) at main.c:223
>
> Linux yen 4.2.1-300.fc23.x86_64+debug #1 SMP Mon Sep 21 21:58:30 UTC 2015
> x86_64 x86_64 x86_64 GNU/Linux
> gcc (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4)
>
> Postgres 9.4.4 is working well
>

git bisect shows

4ea51cdfe85ceef8afabceb03c446574daa0ac23 is the first bad commit
commit 4ea51cdfe85ceef8afabceb03c446574daa0ac23
Author: Robert Haas <rhaas(at)postgresql(dot)org>
Date: Mon Jan 19 15:20:31 2015 -0500

Use abbreviated keys for faster sorting of text datums.

This commit extends the SortSupport infrastructure to allow operator
classes the option to provide abbreviated representations of Datums;
in the case of text, we abbreviate by taking the first few characters
of the strxfrm() blob. If the abbreviated comparison is insufficent
to resolve the comparison, we fall back on the normal comparator.
This can be much faster than the old way of doing sorting if the
first few bytes of the string are usually sufficient to resolve the
comparison.

There is the potential for a performance regression if all of the
strings to be sorted are identical for the first 8+ characters and
differ only in later positions; therefore, the SortSupport machinery
now provides an infrastructure to abort the use of abbreviation if
it appears that abbreviation is producing comparatively few distinct
keys. HyperLogLog, a streaming cardinality estimator, is included in
this commit and used to make that determination for text.

Peter Geoghegan, reviewed by me.

>
> Regards
>
> Pavel
>
>
>
>
>