Thread: check fails on Fedora 23
Hi
I am testing PostgreSQL (master) on Fedora 23. The queryELECT 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);
Program terminated with signal SIGABRT, Aborted.
#0 0x00007f3e1dfe5a98 in __GI_raise (sig=sig@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@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@entry=0x935157 "!(compareResult < 0)",
errorType=errorType@entry=0x802217 "FailedAssertion", fileName=fileName@entry=0x935147 "nodeMergejoin.c",
lineNumber=lineNumber@entry=942) at assert.c:54
#3 0x00000000005eba9f in ExecMergeJoin (node=node@entry=0x175f120) at nodeMergejoin.c:942
#4 0x00000000005d3958 in ExecProcNode (node=node@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@entry=0x16bed38, forward=forward@entry=1 '\001', count=0,
count@entry=9223372036854775807, dest=dest@entry=0x177d1e0) at pquery.c:942
#8 0x00000000006de57e in PortalRun (portal=portal@entry=0x16bed38, count=count@entry=9223372036854775807,
isTopLevel=isTopLevel@entry=1 '\001', dest=dest@entry=0x177d1e0, altdest=altdest@entry=0x177d1e0,
completionTag=completionTag@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@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@entry=8, argv=argv@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)
2015-10-04 10:50 GMT+02:00 Pavel Stehule <pavel.stehule@gmail.com>:
Postgres 9.4.4 is working wellfails on assertHiI 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);
Program terminated with signal SIGABRT, Aborted.
#0 0x00007f3e1dfe5a98 in __GI_raise (sig=sig@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@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@entry=0x935157 "!(compareResult < 0)",
errorType=errorType@entry=0x802217 "FailedAssertion", fileName=fileName@entry=0x935147 "nodeMergejoin.c",
lineNumber=lineNumber@entry=942) at assert.c:54
#3 0x00000000005eba9f in ExecMergeJoin (node=node@entry=0x175f120) at nodeMergejoin.c:942
#4 0x00000000005d3958 in ExecProcNode (node=node@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@entry=0x16bed38, forward=forward@entry=1 '\001', count=0,
count@entry=9223372036854775807, dest=dest@entry=0x177d1e0) at pquery.c:942
#8 0x00000000006de57e in PortalRun (portal=portal@entry=0x16bed38, count=count@entry=9223372036854775807,
isTopLevel=isTopLevel@entry=1 '\001', dest=dest@entry=0x177d1e0, altdest=altdest@entry=0x177d1e0,
completionTag=completionTag@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@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@entry=8, argv=argv@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)
git bisect shows
4ea51cdfe85ceef8afabceb03c446574daa0ac23 is the first bad commit
commit 4ea51cdfe85ceef8afabceb03c446574daa0ac23
Author: Robert Haas <rhaas@postgresql.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.
4ea51cdfe85ceef8afabceb03c446574daa0ac23 is the first bad commit
commit 4ea51cdfe85ceef8afabceb03c446574daa0ac23
Author: Robert Haas <rhaas@postgresql.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.
PavelRegards
#15 0x0000000000469376 in main (argc=8, argv=0x16a45e0) at main.c:223Postgres 9.4.4 is working well
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)
configured with defaults - only --enable-cassert
Regards
Pavel
Pavel Stehule <pavel.stehule@gmail.com> writes:
> 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
Works for me ... what locale/collation are you running in?
regards, tom lane
2015-10-04 16:37 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:
LANG=cs_CZ.UTF-8
Pavel Stehule <pavel.stehule@gmail.com> writes:
> 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
Works for me ... what locale/collation are you running in?
LANG=cs_CZ.UTF-8
Regards
Pavel
regards, tom lane
2015-10-04 17:07 GMT+02:00 Pavel Stehule <pavel.stehule@gmail.com>:
2015-10-04 16:37 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:Pavel Stehule <pavel.stehule@gmail.com> writes:
> 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
Works for me ... what locale/collation are you running in?
LANG=cs_CZ.UTF-8
it depends on locale - it is working with C or en_US.UTF-8, but doesn't work with Czech locale
Pavel
RegardsPavel
regards, tom lane
> fails on assert
Works for me ... what locale/collation are you running in?
LANG=cs_CZ.UTF-8it depends on locale - it is working with C or en_US.UTF-8, but doesn't work with Czech locale
and fails with Hungarian locales too
PavelRegardsPavel
regards, tom lane
On 10/04/2015 11:35 AM, Pavel Stehule wrote: > > > > > fails on assert > > Works for me ... what locale/collation are you running in? > > > LANG=cs_CZ.UTF-8 > > > it depends on locale - it is working with C or en_US.UTF-8, but > doesn't work with Czech locale > > > and fails with Hungarian locales too > > > 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. cheers andrew
2015-10-04 17:52 GMT+02:00 Andrew Dunstan <andrew@dunslane.net>:
On 10/04/2015 11:35 AM, Pavel Stehule wrote:
> fails on assert
Works for me ... what locale/collation are you running in?
LANG=cs_CZ.UTF-8
it depends on locale - it is working with C or en_US.UTF-8, but
doesn't work with Czech locale
and fails with Hungarian locales too
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.
Hard to say what can be wrong:
* locale
* gcc
* glibc
Regards
Pavel
cheers
andrew
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.
It is working on F22 - so it is looking as regression in some fedora components.
can somebody repeat check on FC23?
Regards
Pavel
On 10/04/2015 12:52 PM, Pavel Stehule 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. > > > It is working on F22 - so it is looking as regression in some fedora > components. > > can somebody repeat check on FC23? Yes, I have reproduced it. cheers andrew
On Sun, Oct 4, 2015 at 11:52 AM, Andrew Dunstan <andrew@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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Wed, Oct 7, 2015 at 9:49 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Sun, Oct 4, 2015 at 11:52 AM, Andrew Dunstan <andrew@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 wonder if Glibc bug 18589 is relevant. Bug 18934 says "Note that these unittests pass with glibc-2.21 but fail with 2.22 and current git due to bug 18589 which points to a broken change in the collate algorithm that needs to be reverted first." Hungarian is mentioned. Doesn't Fedora 23 include glibc-2.22? Is it possible that that bug affects strcoll but not strxfrm? https://sourceware.org/bugzilla/show_bug.cgi?id=18589 https://sourceware.org/bugzilla/show_bug.cgi?id=18934 -- Thomas Munro http://www.enterprisedb.com
On 10/06/2015 04:49 PM, Robert Haas wrote:
> On Sun, Oct 4, 2015 at 11:52 AM, Andrew Dunstan <andrew@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_procAS 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;
endloop;
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
On 10/06/2015 05:45 PM, Thomas Munro wrote: > On Wed, Oct 7, 2015 at 9:49 AM, Robert Haas <robertmhaas@gmail.com> wrote: >> On Sun, Oct 4, 2015 at 11:52 AM, Andrew Dunstan <andrew@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 wonder if Glibc bug 18589 is relevant. Bug 18934 says "Note that > these unittests pass with glibc-2.21 but fail with 2.22 and current > git due to bug 18589 which points to a broken change in the collate > algorithm that needs to be reverted first." Hungarian is mentioned. > Doesn't Fedora 23 include glibc-2.22? Is it possible that that bug > affects strcoll but not strxfrm? > > https://sourceware.org/bugzilla/show_bug.cgi?id=18589 > https://sourceware.org/bugzilla/show_bug.cgi?id=18934 > Yes, it's 2.22: [vagrant@localhost ~ ]$ rpm -q -a | grep glibc glibc-2.22-3.fc23.x86_64 glibc-devel-2.22-3.fc23.x86_64 glibc-common-2.22-3.fc23.x86_64 glibc-headers-2.22-3.fc23.x86_64 cheers andrew
On Tuesday 06 of October 2015 17:59:23 Andrew Dunstan wrote: > > On 10/06/2015 05:45 PM, Thomas Munro wrote: > > On Wed, Oct 7, 2015 at 9:49 AM, Robert Haas <robertmhaas@gmail.com> wrote: > >> On Sun, Oct 4, 2015 at 11:52 AM, Andrew Dunstan <andrew@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 wonder if Glibc bug 18589 is relevant. Bug 18934 says "Note that > > these unittests pass with glibc-2.21 but fail with 2.22 and current > > git due to bug 18589 which points to a broken change in the collate > > algorithm that needs to be reverted first." Hungarian is mentioned. > > Doesn't Fedora 23 include glibc-2.22? Is it possible that that bug > > affects strcoll but not strxfrm? > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=18589 > > https://sourceware.org/bugzilla/show_bug.cgi?id=18934 > > > > > Yes, it's 2.22: > > [vagrant@localhost ~ ]$ rpm -q -a | grep glibc > glibc-2.22-3.fc23.x86_64 > glibc-devel-2.22-3.fc23.x86_64 > glibc-common-2.22-3.fc23.x86_64 > glibc-headers-2.22-3.fc23.x86_64 > > cheers > > andrew Yup, broken glibc: https://bugzilla.redhat.com/show_bug.cgi?id=1269895 Pavel