Current CVS of postgres is completely broken.

initdb fails with SIG11 during the 'creation of template1'

--debug doesn't show anything being written.

Several regression tests have postmaster crashing.

These appeared somewhere between 4 days ago and yesterday.

I'm afraid I really don't know where to start debugging the problem.
--
Rod Taylor

Your eyes are weary from staring at the CRT. You feel sleepy. Notice
how restful it is to watch the cursor blink. Close your eyes. The
opinions stated above are yours. You cannot imagine why you ever felt
otherwise.

Search Discussions

  • Greg Copeland at Mar 6, 2002 at 11:46 pm
    I get this from initdb:

    [gcope@mouse pgsql]$ initdb
    The files belonging to this database system will be owned by user
    "gcope".
    This user must also own the server process.

    Fixing permissions on existing directory /usr/local/src/pgsql/data... ok
    creating directory /usr/local/src/pgsql/data/base... ok
    creating directory /usr/local/src/pgsql/data/global... ok
    creating directory /usr/local/src/pgsql/data/pg_xlog... ok
    creating directory /usr/local/src/pgsql/data/pg_clog... ok
    creating template1 database in /usr/local/src/pgsql/data/base/1...
    /usr/bin/initdb: line 473: 1234 Broken pipe cat
    "$POSTGRES_BKI"
    1235 | sed -e
    "s/POSTGRES/$POSTGRES_SUPERUSERNAME/g" -e "s/ENCODING/$MULTIBYTEID/g"
    1236 Segmentation fault | "$PGPATH"/postgres -boot -x1
    $PGSQL_OPT $BACKEND_TALK_ARG template1

    initdb failed.

    On Wed, 2002-03-06 at 10:39, Rod Taylor wrote:
    Current CVS of postgres is completely broken.

    initdb fails with SIG11 during the 'creation of template1'

    --debug doesn't show anything being written.

    Several regression tests have postmaster crashing.

    These appeared somewhere between 4 days ago and yesterday.

    I'm afraid I really don't know where to start debugging the problem.
    --
    Rod Taylor

    Your eyes are weary from staring at the CRT. You feel sleepy. Notice
    how restful it is to watch the cursor blink. Close your eyes. The
    opinions stated above are yours. You cannot imagine why you ever felt
    otherwise.



    ---------------------------(end of broadcast)---------------------------
    TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
  • Neil Conway at Mar 7, 2002 at 4:26 am

    On Wed, 2002-03-06 at 11:39, Rod Taylor wrote:
    Current CVS of postgres is completely broken.
    Yes, I see this as well. The likely culprit seems to be applying patches
    that conflict with one another...
    I'm afraid I really don't know where to start debugging the problem.
    Well, there is a shift/reduce conflict in gram.y; there may be other
    problems, but that's the first one I saw.

    Cheers,

    Neil

    --
    Neil Conway <neilconway@rogers.com>
    PGP Key ID: DB3C29FC
  • Tom Lane at Mar 7, 2002 at 5:21 am

    Neil Conway writes:
    Yes, I see this as well.
    By my count the breakage from the DOMAIN patch is:
    1 shift/reduce conflict in gram.y
    3 gcc warnings (at least one being obviously a bug)
    1 core dump during regression tests

    Bruce, what in the heck were you doing applying this patch? You knew
    darn well it had not been meaningfully reviewed. Not bothering to check
    for compile problems or regression failures before applying is
    unforgivably sloppy work. I don't blame the submitter; I blame you,
    who should have known better.

    regards, tom lane
  • Bruce Momjian at Mar 7, 2002 at 5:55 am

    Tom Lane wrote:
    Neil Conway <nconway@klamath.dyndns.org> writes:
    Yes, I see this as well.
    By my count the breakage from the DOMAIN patch is:
    1 shift/reduce conflict in gram.y
    3 gcc warnings (at least one being obviously a bug)
    1 core dump during regression tests

    Bruce, what in the heck were you doing applying this patch? You knew
    darn well it had not been meaningfully reviewed. Not bothering to check
    for compile problems or regression failures before applying is
    unforgivably sloppy work. I don't blame the submitter; I blame you,
    who should have known better.
    You can blame me all you want. That was in the queue, and no one
    objected, so I did my best. If you don't want to forgive me, don't.

    In fact, this whole indignation thing is starting to tire me. This is an
    open-source project. People do the best they can. Just make the best of
    it and move on.

    If this is the worst that has happened from my applying all those back
    patches, I am happy.

    I do compile tests regularly, and regression tests periodically. I do
    not do it for every patch but more for every batch of patches.

    Now, if people would like the patch backed out, it can be easily done.

    --
    Bruce Momjian | http://candle.pha.pa.us
    pgman@candle.pha.pa.us | (610) 853-3000
    + If your life is a hard drive, | 830 Blythe Avenue
    + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
  • Jan Wieck at Mar 7, 2002 at 3:17 pm

    Bruce Momjian wrote:
    Tom Lane wrote:
    Neil Conway <nconway@klamath.dyndns.org> writes:
    Yes, I see this as well.
    By my count the breakage from the DOMAIN patch is:
    1 shift/reduce conflict in gram.y
    3 gcc warnings (at least one being obviously a bug)
    1 core dump during regression tests

    Bruce, what in the heck were you doing applying this patch? You knew
    darn well it had not been meaningfully reviewed. Not bothering to check
    for compile problems or regression failures before applying is
    unforgivably sloppy work. I don't blame the submitter; I blame you,
    who should have known better.
    You can blame me all you want. That was in the queue, and no one
    objected, so I did my best. If you don't want to forgive me, don't.

    In fact, this whole indignation thing is starting to tire me. This is an
    open-source project. People do the best they can. Just make the best of
    it and move on.

    If this is the worst that has happened from my applying all those back
    patches, I am happy.
    Sorry Bruce, but just because your patch queue is very long
    due to the delays in the 7.2 release cycle is no excuse to
    work sloppy now. Rushing things in is not the solution.


    Jan

    --

    #======================================================================#
    # It's easier to get forgiveness for being wrong than for being right. #
    # Let's break this rule - forgive me. #
    #================================================== JanWieck@Yahoo.com #



    _________________________________________________________
    Do You Yahoo!?
    Get your free @yahoo.com address at http://mail.yahoo.com
  • Fernando Nasser at Mar 7, 2002 at 5:52 pm
    In GDB we have this notion of a "write after approval" list,
    so more people can be given write access to the repository with
    the condition that they can only check things in after someone
    (which is entitled to do so) approves the patch. This reduces
    the burden on the person who has to check in things for everyone else.

    --
    Fernando Nasser
    Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
    2323 Yonge Street, Suite #300
    Toronto, Ontario M4P 2C9
  • Bruce Momjian at Mar 7, 2002 at 6:09 pm

    Jan Wieck wrote:
    Bruce Momjian wrote:
    Tom Lane wrote:
    By my count the breakage from the DOMAIN patch is:
    1 shift/reduce conflict in gram.y
    3 gcc warnings (at least one being obviously a bug)
    1 core dump during regression tests

    Bruce, what in the heck were you doing applying this patch? You knew
    darn well it had not been meaningfully reviewed. Not bothering to check
    for compile problems or regression failures before applying is
    unforgivably sloppy work. I don't blame the submitter; I blame you,
    who should have known better.
    You can blame me all you want. That was in the queue, and no one
    objected, so I did my best. If you don't want to forgive me, don't.

    In fact, this whole indignation thing is starting to tire me. This is an
    open-source project. People do the best they can. Just make the best of
    it and move on.

    If this is the worst that has happened from my applying all those back
    patches, I am happy.
    Sorry Bruce, but just because your patch queue is very long
    due to the delays in the 7.2 release cycle is no excuse to
    work sloppy now. Rushing things in is not the solution.
    No, this was not in a very old patch. First patch appeared late
    February, there was discussion, a second patch appeared early March, and
    there was no discussion on it. The patch had a file of sample queries,
    and someone else had even submitted a psql patch based on the feature.
    So, actually, it looked pretty good.

    In fact, the patch did have a compile problem when applied because it
    used our commandTag that isn't used anymore in that place, so I fixed
    it.

    However, that wasn't really my issue. I am happy to back out anything,
    and have does so for both patches listed above. I will contact the
    authors and get an updated version that we can discuss and request more
    testing.

    My issue is that trying to blame someone isn't the proper way to address
    these issues.

    --
    Bruce Momjian | http://candle.pha.pa.us
    pgman@candle.pha.pa.us | (610) 853-3000
    + If your life is a hard drive, | 830 Blythe Avenue
    + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
  • Rod Taylor at Mar 7, 2002 at 6:19 pm

    In fact, the patch did have a compile problem when applied because it
    used our commandTag that isn't used anymore in that place, so I fixed
    it.
    Speaking of which, whats the proper way to do this? I get ??? after
    all commands now.
  • Bruce Momjian at Mar 7, 2002 at 6:24 pm

    Rod Taylor wrote:
    In fact, the patch did have a compile problem when applied because it
    used our commandTag that isn't used anymore in that place, so I fixed
    it.
    Speaking of which, whats the proper way to do this? I get ??? after
    all commands now.
    Good question. I see commandTag set to "CREATE" in many places in
    postgres.c. I believe you need to add an additional 'case' for the
    domain stuff.

    --
    Bruce Momjian | http://candle.pha.pa.us
    pgman@candle.pha.pa.us | (610) 853-3000
    + If your life is a hard drive, | 830 Blythe Avenue
    + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
  • Greg Copeland at Mar 7, 2002 at 10:21 pm
    If I do "initdb" with the "-d" option, postgres will crash during the
    bootstrap. I think it's because postgres is attempting to strlen(NULL)
    while trying to build a string during it's option parsing.

    This happen for anyone else?

    Greg


    On Wed, 2002-03-06 at 22:26, Neil Conway wrote:
    On Wed, 2002-03-06 at 11:39, Rod Taylor wrote:
    Current CVS of postgres is completely broken.
    Yes, I see this as well. The likely culprit seems to be applying patches
    that conflict with one another...
    I'm afraid I really don't know where to start debugging the problem.
    Well, there is a shift/reduce conflict in gram.y; there may be other
    problems, but that's the first one I saw.

    Cheers,

    Neil

    --
    Neil Conway <neilconway@rogers.com>
    PGP Key ID: DB3C29FC


    ---------------------------(end of broadcast)---------------------------
    TIP 3: if posting/reading through Usenet, please send an appropriate
    subscribe-nomail command to majordomo@postgresql.org so that your
    message can get through to the mailing list cleanly
  • Bruce Momjian at Mar 7, 2002 at 10:40 pm
    Greg Copeland wrote:

    Checking application/pgp-signature: FAILURE
    -- Start of PGP signed section.
    If I do "initdb" with the "-d" option, postgres will crash during the
    bootstrap. I think it's because postgres is attempting to strlen(NULL)
    while trying to build a string during it's option parsing.

    This happen for anyone else?
    Yes, I see that here. Let me look at it. It may have to do with the
    elog() changes.

    --
    Bruce Momjian | http://candle.pha.pa.us
    pgman@candle.pha.pa.us | (610) 853-3000
    + If your life is a hard drive, | 830 Blythe Avenue
    + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
  • Greg Copeland at Mar 7, 2002 at 10:50 pm
    Guess I failed to mention that I had just done an update and rebuild
    just minutes prior to reporting it.

    Greg

    On Thu, 2002-03-07 at 16:37, Bruce Momjian wrote:
    Greg Copeland wrote:

    Checking application/pgp-signature: FAILURE
    -- Start of PGP signed section.
    If I do "initdb" with the "-d" option, postgres will crash during the
    bootstrap. I think it's because postgres is attempting to strlen(NULL)
    while trying to build a string during it's option parsing.

    This happen for anyone else?
    Yes, I see that here. Let me look at it. It may have to do with the
    elog() changes.

    --
    Bruce Momjian | http://candle.pha.pa.us
    pgman@candle.pha.pa.us | (610) 853-3000
    + If your life is a hard drive, | 830 Blythe Avenue
    + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
  • Bruce Momjian at Mar 7, 2002 at 11:30 pm
    Greg Copeland wrote:

    Checking application/pgp-signature: FAILURE
    -- Start of PGP signed section.
    Guess I failed to mention that I had just done an update and rebuild
    just minutes prior to reporting it.
    Yes, I see initdb -d failures here with current CVS. Investigating.

    --
    Bruce Momjian | http://candle.pha.pa.us
    pgman@candle.pha.pa.us | (610) 853-3000
    + If your life is a hard drive, | 830 Blythe Avenue
    + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
  • Fernando Nasser at Mar 7, 2002 at 10:40 pm

    Greg Copeland wrote:

    If I do "initdb" with the "-d" option, postgres will crash during the
    bootstrap. I think it's because postgres is attempting to strlen(NULL)
    while trying to build a string during it's option parsing.

    This happen for anyone else?

    Greg
    Yes, but it is fixed now. cvs update -d -P should solve it.

    On Wed, 2002-03-06 at 22:26, Neil Conway wrote:
    On Wed, 2002-03-06 at 11:39, Rod Taylor wrote:
    Current CVS of postgres is completely broken.
    Yes, I see this as well. The likely culprit seems to be applying patches
    that conflict with one another...
    I'm afraid I really don't know where to start debugging the problem.
    Well, there is a shift/reduce conflict in gram.y; there may be other
    problems, but that's the first one I saw.

    Cheers,

    Neil

    --
    Neil Conway <neilconway@rogers.com>
    PGP Key ID: DB3C29FC


    ---------------------------(end of broadcast)---------------------------
    TIP 3: if posting/reading through Usenet, please send an appropriate
    subscribe-nomail command to majordomo@postgresql.org so that your
    message can get through to the mailing list cleanly
    ------------------------------------------------------------------------
    Name: signature.asc
    signature.asc Type: application/pgp-signature
    Description: This is a digitally signed message part
    --
    Fernando Nasser
    Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
    2323 Yonge Street, Suite #300
    Toronto, Ontario M4P 2C9
  • Tom Lane at Mar 8, 2002 at 12:48 am

    Greg Copeland writes:
    If I do "initdb" with the "-d" option, postgres will crash during the
    bootstrap. I think it's because postgres is attempting to strlen(NULL)
    while trying to build a string during it's option parsing.
    Fixed --- problem was bad option information passed to getopt().

    regards, tom lane
  • Bruce Momjian at Mar 8, 2002 at 12:51 am

    Tom Lane wrote:
    Greg Copeland <greg@CopelandConsulting.Net> writes:
    If I do "initdb" with the "-d" option, postgres will crash during the
    bootstrap. I think it's because postgres is attempting to strlen(NULL)
    while trying to build a string during it's option parsing.
    Fixed --- problem was bad option information passed to getopt().
    Yes, I suspected it was somewhere in there but had to run out for an
    hour. Was just looking at it. Before bootstrap just took -d while it
    now takes '-d level'. I was sure I missed something and I see now it
    was getopt(). Thanks.

    --
    Bruce Momjian | http://candle.pha.pa.us
    pgman@candle.pha.pa.us | (610) 853-3000
    + If your life is a hard drive, | 830 Blythe Avenue
    + Christ can be your backup. | Drexel Hill, Pennsylvania 19026

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedMar 6, '02 at 4:40p
activeMar 8, '02 at 12:51a
posts17
users7
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase