Hi,

I've installed a 8.1.0 PostgreSQL server on a SCO OpenServer 5.0.6. It
seemed to work well with psql and such tools. I tried to connect to
this server with pgAdmin3 and a query failed. I tried to find which
part of the query was wrong and I have a strange result :

SELECT 1 FROM pg_language WHERE lanispl IS TRUE;
this one crashes the server.

SELECT 1 FROM pg_language WHERE lanispl = true;
works.

It seemed to me that "IS TRUE" is the culprit so I tried something else
SELECT lanispl IS TRUE FROM pg_language;
and it works.

If I create a table for testing purpose, I can add a where clause with
"IS TRUE".

Last thing I tried was to launch postgres on standalone. With the first query,
server crashed with a «Memory fault(coredump)». I can send you the all log if
you want.

This behavior happens on another server (SCO too) but not on any Linux
that I tried. I've attached the patch I apply to be able to build
PostgreSQL on SCO OpenServer. I'm not 100% sure it isn't faulty.

Did something like this already happened to someone ? Do you know of
any test I can do ?

Regards.

Search Discussions

  • Martijn van Oosterhout at Nov 11, 2005 at 2:17 pm

    On Thu, Nov 10, 2005 at 11:53:04PM +0100, Guillaume LELARGE wrote:
    Hi,

    I've installed a 8.1.0 PostgreSQL server on a SCO OpenServer 5.0.6. It
    seemed to work well with psql and such tools. I tried to connect to
    this server with pgAdmin3 and a query failed. I tried to find which
    part of the query was wrong and I have a strange result :

    SELECT 1 FROM pg_language WHERE lanispl IS TRUE;
    this one crashes the server.

    SELECT 1 FROM pg_language WHERE lanispl = true;
    works.
    Does this pass regression testing (ie make check)? It looks like it's
    dying all over the please. Posting a backtrace (bt in gdb) would be
    more helpful.

    Have a nice day?
    --
    Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
    Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
    tool for doing 5% of the work and then sitting around waiting for someone
    else to do the other 95% so you can sue them.
  • Bruce Momjian at Nov 15, 2005 at 9:58 pm
    The SCO compiler is so buggy (and for so many years) I see no reason to
    even look at a bug report from someone using it.

    ---------------------------------------------------------------------------

    Martijn van Oosterhout wrote:
    -- Start of PGP signed section.
    On Thu, Nov 10, 2005 at 11:53:04PM +0100, Guillaume LELARGE wrote:
    Hi,

    I've installed a 8.1.0 PostgreSQL server on a SCO OpenServer 5.0.6. It
    seemed to work well with psql and such tools. I tried to connect to
    this server with pgAdmin3 and a query failed. I tried to find which
    part of the query was wrong and I have a strange result :

    SELECT 1 FROM pg_language WHERE lanispl IS TRUE;
    this one crashes the server.

    SELECT 1 FROM pg_language WHERE lanispl = true;
    works.
    Does this pass regression testing (ie make check)? It looks like it's
    dying all over the please. Posting a backtrace (bt in gdb) would be
    more helpful.

    Have a nice day?
    --
    Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
    Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
    tool for doing 5% of the work and then sitting around waiting for someone
    else to do the other 95% so you can sue them.
    -- End of PGP section, PGP failed!

    --
    Bruce Momjian | http://candle.pha.pa.us
    pgman@candle.pha.pa.us | (610) 359-1001
    + If your life is a hard drive, | 13 Roberts Road
    + Christ can be your backup. | Newtown Square, Pennsylvania 19073
  • Larry Rosenman at Nov 15, 2005 at 11:12 pm

    Bruce Momjian wrote:
    The SCO compiler is so buggy (and for so many years) I see no reason
    to even look at a bug report from someone using it.
    I **REALLY** wish you would STOP saying that, Bruce. The current OpenServer
    Compiler (UDK), is the same as on UnixWare, and is **MUCH** better than the
    Old SVR3 compiler.

    We **REALLY** **SHOULD** look at it.

    I'll take the bug report directly to SCO if I get enough detail.

    LER

    >
    ---------------------------------------------------------------------------
    Martijn van Oosterhout wrote:
    -- Start of PGP signed section.
    On Thu, Nov 10, 2005 at 11:53:04PM +0100, Guillaume LELARGE wrote:
    Hi,

    I've installed a 8.1.0 PostgreSQL server on a SCO OpenServer 5.0.6.
    It seemed to work well with psql and such tools. I tried to connect
    to this server with pgAdmin3 and a query failed. I tried to find
    which part of the query was wrong and I have a strange result :

    SELECT 1 FROM pg_language WHERE lanispl IS TRUE; this one crashes
    the server.

    SELECT 1 FROM pg_language WHERE lanispl = true; works.
    Does this pass regression testing (ie make check)? It looks like it's
    dying all over the please. Posting a backtrace (bt in gdb) would be
    more helpful.

    Have a nice day?
    --
    Martijn van Oosterhout <kleptog@svana.org>
    http://svana.org/kleptog/
    Patent. n. Genius is 5% inspiration and 95% perspiration. A patent
    is a tool for doing 5% of the work and then sitting around waiting
    for someone else to do the other 95% so you can sue them.
    -- End of PGP section, PGP failed!


    --
    Larry Rosenman http://www.lerctr.org/~ler
    Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
    US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 US
  • Bruce Momjian at Nov 16, 2005 at 1:46 am

    Larry Rosenman wrote:
    Bruce Momjian wrote:
    The SCO compiler is so buggy (and for so many years) I see no reason
    to even look at a bug report from someone using it.
    I **REALLY** wish you would STOP saying that, Bruce. The current OpenServer
    I will not if I believe it is true.
    Compiler (UDK), is the same as on UnixWare, and is **MUCH** better than the
    Old SVR3 compiler.

    We **REALLY** **SHOULD** look at it.

    I'll take the bug report directly to SCO if I get enough detail.
    And I think this adds weight to my opinions.

    --
    Bruce Momjian | http://candle.pha.pa.us
    pgman@candle.pha.pa.us | (610) 359-1001
    + If your life is a hard drive, | 13 Roberts Road
    + Christ can be your backup. | Newtown Square, Pennsylvania 19073
  • Guillaume Lelarge at Nov 22, 2005 at 6:02 pm
    Sorry for answering this late.

    2005/11/16, Larry Rosenman <ler@lerctr.org>:
    Bruce Momjian wrote:
    The SCO compiler is so buggy (and for so many years) I see no reason
    to even look at a bug report from someone using it.
    I **REALLY** wish you would STOP saying that, Bruce. The current OpenServer
    Compiler (UDK), is the same as on UnixWare, and is **MUCH** better than the
    Old SVR3 compiler.

    We **REALLY** **SHOULD** look at it.

    I'll take the bug report directly to SCO if I get enough detail.
    I was using cc, exactly "SCO UNIX Development System Release 5.1.2A
    27Jul00". Last week, I tried with "UX:i386cc: INFO: SCO UNIX
    Development System Release 5.2.0A 07Oct05" but I had the same
    results. I think I'm doing something wrong but I don't know what.

    I launched postgres in standalone mode and a core file is created. I
    used gdb on it to see the backtrace :
    (gdb) bt
    #0 0x081bf5fd in booltestsel ()
    #1 0x08141125 in clause_selectivity ()
    #2 0x081409d2 in clauselist_selectivity ()
    #3 0x0814295b in set_baserel_size_estimates ()
    #4 0x0813ff42 in set_plain_rel_pathlist ()
    #5 0x0813ff12 in set_base_rel_pathlists ()
    #6 0x0813fe1d in make_one_rel ()
    #7 0x0814b455 in query_planner ()
    #8 0x0814bfa0 in grouping_planner ()
    #9 0x0814ba11 in subquery_planner ()
    #10 0x0814b6c7 in planner ()
    #11 0x08181e07 in pg_plan_query ()
    #12 0x08181ea0 in pg_plan_queries ()
    #13 0x081820ce in exec_simple_query ()
    #14 0x081849dd in PostgresMain ()
    #15 0x08161d92 in BackendRun ()
    #16 0x081616c9 in BackendStartup ()
    #17 0x0815fba8 in ServerLoop ()
    #18 0x0815f67c in PostmasterMain ()
    #19 0x08127d91 in main ()
    #20 0x08074d1a in _start ()

    So I tried to work on the booltestsel function
    (src/backend/utils/adt/selfuncs.c file). I added some elog statements
    to see where problems arise. When I put an elog statement in these
    lines, my issue is gone :
    /*
    * Get first MCV frequency and derive frequency for true
    */
    if (DatumGetBool(values[0]))
    freq_true = numbers[0];
    else
    freq_true = 1.0 - numbers[0] - freq_null;

    /*
    * Next derive frequency for false. Then use these as appropriate
    * to derive frequency for each case.
    */
    freq_false = 1.0 - freq_true - freq_null;

    So, I don't get it. I have absolutely no problems with gcc on linux,
    but I have this issue on cc (5.1.2A and 5.2.0A releases).

    Larry, if you have some more questions, please ask. I don't know whose
    bug it is (c compiler or PostgreSQL... or, perhaps, me) but I want to
    get rit of it.

    Regards.


    --
    Guillaume.
  • Larry Rosenman at Nov 22, 2005 at 11:41 pm
    Sorry for the top post. If you can get a UDK license, that will work
    better.

    LER
    On Nov 22, 2005, at 12:02 PM, Guillaume Lelarge wrote:

    Sorry for answering this late.

    2005/11/16, Larry Rosenman <ler@lerctr.org>:
    Bruce Momjian wrote:
    The SCO compiler is so buggy (and for so many years) I see no reason
    to even look at a bug report from someone using it.
    I **REALLY** wish you would STOP saying that, Bruce. The current
    OpenServer
    Compiler (UDK), is the same as on UnixWare, and is **MUCH** better
    than the
    Old SVR3 compiler.

    We **REALLY** **SHOULD** look at it.

    I'll take the bug report directly to SCO if I get enough detail.
    I was using cc, exactly "SCO UNIX Development System Release 5.1.2A
    27Jul00". Last week, I tried with "UX:i386cc: INFO: SCO UNIX
    Development System Release 5.2.0A 07Oct05" but I had the same
    results. I think I'm doing something wrong but I don't know what.

    I launched postgres in standalone mode and a core file is created. I
    used gdb on it to see the backtrace :
    (gdb) bt
    #0 0x081bf5fd in booltestsel ()
    #1 0x08141125 in clause_selectivity ()
    #2 0x081409d2 in clauselist_selectivity ()
    #3 0x0814295b in set_baserel_size_estimates ()
    #4 0x0813ff42 in set_plain_rel_pathlist ()
    #5 0x0813ff12 in set_base_rel_pathlists ()
    #6 0x0813fe1d in make_one_rel ()
    #7 0x0814b455 in query_planner ()
    #8 0x0814bfa0 in grouping_planner ()
    #9 0x0814ba11 in subquery_planner ()
    #10 0x0814b6c7 in planner ()
    #11 0x08181e07 in pg_plan_query ()
    #12 0x08181ea0 in pg_plan_queries ()
    #13 0x081820ce in exec_simple_query ()
    #14 0x081849dd in PostgresMain ()
    #15 0x08161d92 in BackendRun ()
    #16 0x081616c9 in BackendStartup ()
    #17 0x0815fba8 in ServerLoop ()
    #18 0x0815f67c in PostmasterMain ()
    #19 0x08127d91 in main ()
    #20 0x08074d1a in _start ()
    --
    Larry Rosenman http://www.lerctr.org/~ler
    Phone: +1 214-351-4152 E-Mail: ler@lerctr.org
    US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611
  • Alvaro Herrera at Nov 23, 2005 at 1:06 am

    Larry Rosenman wrote:
    Sorry for the top post. If you can get a UDK license, that will work
    better.
    Oh, so one gets a buggy compiler by default and has to pay for a better
    one? Cool! I'm drooling already, I want one of those SCO things, where
    do I get it? Pity those GCC guys, having only one compiler.

    --
    Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4
    "Use it up, wear it out, make it do, or do without"
  • Larry Rosenman at Nov 23, 2005 at 1:13 am

    On Nov 22, 2005, at 7:04 PM, Alvaro Herrera wrote:

    Larry Rosenman wrote:
    Sorry for the top post. If you can get a UDK license, that will work
    better.
    Oh, so one gets a buggy compiler by default and has to pay for a
    better
    one? Cool! I'm drooling already, I want one of those SCO things,
    where
    do I get it? Pity those GCC guys, having only one compiler.
    no, the old compiler also costs :(.

    It's just that the UDK compiler is the newer one, and works with
    both OpenServer and UnixWare.

    --
    Alvaro Herrera http://www.amazon.com/gp/registry/
    CTMLCN8V17R4
    "Use it up, wear it out, make it do, or do without"
    --
    Larry Rosenman http://www.lerctr.org/~ler
    Phone: +1 214-351-4152 E-Mail: ler@lerctr.org
    US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611
  • Joshua D. Drake at Nov 23, 2005 at 3:30 am

    I **REALLY** wish you would STOP saying that, Bruce. The current OpenServer
    Compiler (UDK), is the same as on UnixWare, and is **MUCH** better than the
    Old SVR3 compiler.

    We **REALLY** **SHOULD** look at it.
    Well actually no, we shouldn't. Regardless of the technical good or
    bad.. We are talking about SCO here.
    The socio-political ramifications of supporting such as beast alone
    should be enough for every
    PostgreSQL and OSS user to run screaming from the building.

    Regardless if what Bruce says is FUD or not the reality is, I seriously
    doubt anyone here wants to
    support or take bug reports for a product that is supported by a company
    that is the complete
    antithesis of everything good about FOSS.

    Sincerely,

    Joshua D. Drake


    --
    The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
    PostgreSQL Replication, Consulting, Custom Development, 24x7 support
    Managed Services, Shared and Dedicated Hosting
    Co-Authors: PLphp, PLperl - http://www.commandprompt.com/
  • Guillaume Lelarge at Nov 23, 2005 at 7:37 am
    2005/11/23, Joshua D. Drake <jd@commandprompt.com>:
    I **REALLY** wish you would STOP saying that, Bruce. The current OpenServer
    Compiler (UDK), is the same as on UnixWare, and is **MUCH** better than the
    Old SVR3 compiler.

    We **REALLY** **SHOULD** look at it.
    Well actually no, we shouldn't. Regardless of the technical good or
    bad.. We are talking about SCO here.
    The socio-political ramifications of supporting such as beast alone
    should be enough for every
    PostgreSQL and OSS user to run screaming from the building.
    I kind of agree with you on this, Josh. Unfortunately, a long time
    ago, in my work, a choice has been made to use SCO with our customers
    (more than 1000). And I'm not the one who can choose to move to
    another OS. I would better use linux, my life would be simpler in many
    ways but I have to deal with this choice.
    Regardless if what Bruce says is FUD or not the reality is, I seriously
    doubt anyone here wants to
    support or take bug reports for a product that is supported by a company
    that is the complete
    antithesis of everything good about FOSS.
    I understand what your positions are and I respect them. But I think
    we should be very careful with what we say because FUD is not a good
    thing, even for us.

    If I posted my message here, it was only to know if someone already
    had this experience and found a way to fix it. It didn't want you to
    put extra code to fix a buggy compiler.


    Regards.


    --
    Guillaume.
  • Guillaume Lelarge at Nov 22, 2005 at 5:42 pm
    Sorry for this late answer. I tried a lot of things and it still doesn't work.

    2005/11/11, Martijn van Oosterhout <kleptog@svana.org>:
    On Thu, Nov 10, 2005 at 11:53:04PM +0100, Guillaume LELARGE wrote:
    Hi,

    I've installed a 8.1.0 PostgreSQL server on a SCO OpenServer 5.0.6. It
    seemed to work well with psql and such tools. I tried to connect to
    this server with pgAdmin3 and a query failed. I tried to find which
    part of the query was wrong and I have a strange result :

    SELECT 1 FROM pg_language WHERE lanispl IS TRUE;
    this one crashes the server.

    SELECT 1 FROM pg_language WHERE lanispl = true;
    works.
    Does this pass regression testing (ie make check)? It looks like it's
    dying all over the please. Posting a backtrace (bt in gdb) would be
    more helpful.
    Some tests failed.. strangely, it seems int4 and int8 share the same
    range. I didn't go further on this because I don't think this will
    resolve my real issue.

    See my next answer to Larry for more informations.


    --
    Guillaume.
  • Tom Lane at Nov 22, 2005 at 5:55 pm

    Guillaume Lelarge writes:
    I've installed a 8.1.0 PostgreSQL server on a SCO OpenServer 5.0.6.
    Some tests failed.. strangely, it seems int4 and int8 share the same
    range.
    This is expected behavior if the platform's C compiler doesn't support
    any 64-bit integer type. We go out of our way to make sure that PG
    will still work (with reduced functionality, ie int8 is really int4)
    on such platforms. But you might prefer to get a better C compiler
    instead.

    regards, tom lane

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedNov 10, '05 at 10:53p
activeNov 23, '05 at 7:37a
posts13
users8
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase