Re: [HACKERS] check fails on Fedora 23
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 wrote: > >> On Sun, Oct 4, 2015 at 11:52 AM, Andrew Dunstan > >> 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
Re: [HACKERS] check fails on Fedora 23
On 10/06/2015 05:45 PM, Thomas Munro wrote: On Wed, Oct 7, 2015 at 9:49 AM, Robert Haas wrote: On Sun, Oct 4, 2015 at 11:52 AM, Andrew Dunstan 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
Re: [HACKERS] check fails on Fedora 23
On 10/06/2015 04:49 PM, Robert Haas wrote:
On Sun, Oct 4, 2015 at 11:52 AM, Andrew Dunstan 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
Re: [HACKERS] check fails on Fedora 23
On Wed, Oct 7, 2015 at 9:49 AM, Robert Haas wrote: > On Sun, Oct 4, 2015 at 11:52 AM, Andrew Dunstan 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
Re: [HACKERS] check fails on Fedora 23
On Sun, Oct 4, 2015 at 11:52 AM, Andrew Dunstan 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
Re: [HACKERS] check fails on Fedora 23
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
Re: [HACKERS] check fails on Fedora 23
> 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
Re: [HACKERS] check fails on Fedora 23
2015-10-04 17:52 GMT+02:00 Andrew Dunstan : > > > 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 >
Re: [HACKERS] check fails on Fedora 23
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
Re: [HACKERS] check fails on Fedora 23
>>> > 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 > > Pavel > > >> >> Regards >> >> Pavel >> >> >> >>> >>> regards, tom lane >>> >> >> >
Re: [HACKERS] check fails on Fedora 23
2015-10-04 17:07 GMT+02:00 Pavel Stehule : > > > 2015-10-04 16:37 GMT+02:00 Tom Lane : > >> Pavel Stehule 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 > > Regards > > Pavel > > > >> >> regards, tom lane >> > >
Re: [HACKERS] check fails on Fedora 23
2015-10-04 16:37 GMT+02:00 Tom Lane : > Pavel Stehule 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 >
Re: [HACKERS] check fails on Fedora 23
Pavel Stehule 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
Re: [HACKERS] check fails on Fedora 23
#15 0x00469376 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
Re: [HACKERS] check fails on Fedora 23
2015-10-04 10:50 GMT+02:00 Pavel Stehule : > 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 0x7f3e1dfe5a98 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 0x7f3e1dfe5a98 in __GI_raise (sig=sig@entry=6) at > ../sysdeps/unix/sysv/linux/raise.c:55 > #1 0x7f3e1dfe769a in __GI_abort () at abort.c:89 > #2 0x007c5401 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 0x005eba9f in ExecMergeJoin (node=node@entry=0x175f120) at > nodeMergejoin.c:942 > #4 0x005d3958 in ExecProcNode (node=node@entry=0x175f120) at > execProcnode.c:480 > #5 0x005cfe87 in ExecutePlan (dest=0x177d1e0, > direction=, numberTuples=0, sendTuples=, > operation=CMD_SELECT, planstate=0x175f120, estate=0x175f008) at > execMain.c:1562 > #6 standard_ExecutorRun (queryDesc=0x16c7e88, direction=, > count=0) at execMain.c:342 > #7 0x006dd038 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 0x006de57e 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 0x006db29b 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\np1.prosrc = p2.prosrc AND\np1.prolang = 12 AND p2.prolang = 12 > AND\n(p1.proisagg = f"...) at postgres.c:1105 > #10 PostgresMain (argc=, argv=argv@entry=0x16a57a0, > dbname=0x16a5500 "regression", username=) > at postgres.c:4033 > #11 0x0046810f in BackendRun (port=0x16c5f50) at postmaster.c:4204 > #12 BackendStartup (port=0x16c5f50) at postmaster.c:3880 > #13 ServerLoop () at postmaster.c:1683 > #14 0x0067e98b in PostmasterMain (argc=argc@entry=8, > argv=argv@entry=0x16a45e0) at postmaster.c:1292 > #15 0x00469376 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 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 > > > > >
[HACKERS] check fails on Fedora 23
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 0x7f3e1dfe5a98 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 0x7f3e1dfe5a98 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55 #1 0x7f3e1dfe769a in __GI_abort () at abort.c:89 #2 0x007c5401 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 0x005eba9f in ExecMergeJoin (node=node@entry=0x175f120) at nodeMergejoin.c:942 #4 0x005d3958 in ExecProcNode (node=node@entry=0x175f120) at execProcnode.c:480 #5 0x005cfe87 in ExecutePlan (dest=0x177d1e0, direction=, numberTuples=0, sendTuples=, operation=CMD_SELECT, planstate=0x175f120, estate=0x175f008) at execMain.c:1562 #6 standard_ExecutorRun (queryDesc=0x16c7e88, direction=, count=0) at execMain.c:342 #7 0x006dd038 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 0x006de57e 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 0x006db29b 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\np1.prosrc = p2.prosrc AND\np1.prolang = 12 AND p2.prolang = 12 AND\n(p1.proisagg = f"...) at postgres.c:1105 #10 PostgresMain (argc=, argv=argv@entry=0x16a57a0, dbname=0x16a5500 "regression", username=) at postgres.c:4033 #11 0x0046810f in BackendRun (port=0x16c5f50) at postmaster.c:4204 #12 BackendStartup (port=0x16c5f50) at postmaster.c:3880 #13 ServerLoop () at postmaster.c:1683 #14 0x0067e98b in PostmasterMain (argc=argc@entry=8, argv=argv@entry=0x16a45e0) at postmaster.c:1292 #15 0x00469376 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 Regards Pavel
