Bad Build

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

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

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

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

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

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, Pennsylvania 19026

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

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:

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

Guess I failed to mention that I had just done an update and rebuild
just minutes prior to reporting it.

Greg

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

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, Pennsylvania 19026