check fails on Fedora 23

2015-10-04 10:50 GMT+02:00 Pavel Stehule <pavel.stehule@gmail.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@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)

Postgres 9.4.4 is working well

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.

#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

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

Regards

Pavel

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

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

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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_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

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers