Thread: Bad Build
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.
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
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
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.y3 gcc warnings (at least one being
obviouslya 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
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, Pennsylvania19026
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
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, Pennsylvania19026
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
> 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.
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, Pennsylvania19026
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
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
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, Pennsylvania19026
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
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, Pennsylvania19026
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().
regards, tom lane
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, Pennsylvania19026