Discussion:
PostgreSQL 7.4.2 on SunOS 4.1.4
(too old to reply)
Cook, Tom
2004-06-09 05:11:28 UTC
Permalink
Hi,
I'm attempting to install PostgreSQL on a SunOS 4.1.4 box. So far,
I've tried various combinations of gcc 2.95.1,.2,.3, PostgreSQL 7.1.3,
7.0.3, 7.3. In some cases, gcc won't build. In others, PostgreSQL
won't build. But in the gcc 2.95.2/pg 7.1.3 case, I've got exactly
the same INITDB problem as Jeff Stevens (post 2002-09-25 09:36:36
PST): ERROR: syntax error at line 2658: unexpected token parse
error.
I'm now trying to get PostgreSQL running on a SunOS 4.1.4 system
(to replace Another Database which costs us a packet each year). There
were only a few minor changes required to get it to compile (I can send
a diff if you like, but probably only once I can run the regression tests).
But while trying to run the regression tests, when initdb is running, I run
into this error:

...
DEBUG: start transaction
DEBUG: close relation (null)
DEBUG: commit transaction
ERROR: syntax error at line 3467: unexpected token "syntax error"
DEBUG: proc_exit(1)
DEBUG: shmem_exit(1)
DEBUG: exit(1)
...

This line number seems to be from postgres.bki, and it appears to be one
short of where the error actually arises - inserting a blank line at line 3468
moves the error to line 3468.

A response to Warren's question suggested that maybe the awk version he
was using was to blame, and was generating incorrect bki files. But I can't
see anything wrong with the bki file generated - the pg_aggregate data does
not suffer from the same problems as noted in the response to Warren's
question, and the area that causes the problem looks like this:

...
)
open pg_depend
close pg_depend
declare unique index pg_aggregate_fnoid_index on pg_aggregate using btree(aggfnoid oid_ops)
declare unique index pg_am_name_index on pg_am using btree(amname name_ops)
...

The first 'declare unique index' line is the one that is causing the problem -
commenting it out just moves the same error message to the next line.

I have not regenerated the bison-generated parser source file - it is the one
that comes with PostgreSQL 7.4.2.

Does anyone have any ideas what could cause this error?

Thanks,
Tom Cook
--
Duct tape is like the Force, it has a light side, a dark side, and holds the universe together
- gcc bug database

--------------------------------------------------------------------------------------------------------------------
This e-mail (including attachments) is confidential information of Australian Submarine Corporation Pty Limited (ASC). It may also be legally privileged. Unauthorised use and disclosure is prohibited. ASC is not taken to have waived confidentiality or privilege if this e-mail was sent to you in error. If you have received it in error, please notify the sender promptly. While ASC takes steps to identify and eliminate viruses, it cannot confirm that this e-mail is free from them. You should scan this e-mail for viruses before it is used. The statements in this e-mail are those of the sender only, unless specifically stated to be those of ASC by someone with authority to do so.
Tom Lane
2004-06-09 14:48:09 UTC
Permalink
Post by Cook, Tom
ERROR: syntax error at line 3467: unexpected token "syntax error"
This line number seems to be from postgres.bki, and it appears to be
one short of where the error actually arises - inserting a blank line
at line 3468 moves the error to line 3468.
Hmm, both the weird phrasing of the error message and the off-by-one
line count are pretty obvious bugs now that I look at bootscanner.l.
I guess nobody noticed because so few people have ever seen an actual
syntax error here.
Post by Cook, Tom
The first 'declare unique index' line is the one that is causing the
problem - commenting it out just moves the same error message to the
next line.
It looks fine to me too. I think that either the bootstrap lexer
or parser must be broken on your machine.
Post by Cook, Tom
I have not regenerated the bison-generated parser source file - it is
the one that comes with PostgreSQL 7.4.2.
Are you speaking specifically of

src/backend/bootstrap/bootparse.c
src/backend/bootstrap/bootscanner.c
src/backend/bootstrap/bootstrap_tokens.h

Make doubly sure that these didn't get regenerated. If they didn't, the
only other theory that comes to mind is a compiler bug. Which compiler
are you using exactly?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ***@postgresql.org so that your
message can get through to the mailing list cleanly
Cook, Tom
2004-06-10 03:39:23 UTC
Permalink
Tom Lane writes:
[snip]
Post by Tom Lane
Post by Cook, Tom
I have not regenerated the bison-generated parser source file - it is
the one that comes with PostgreSQL 7.4.2.
Are you speaking specifically of
src/backend/bootstrap/bootparse.c
src/backend/bootstrap/bootscanner.c
src/backend/bootstrap/bootstrap_tokens.h
Make doubly sure that these didn't get regenerated. If they didn't, the
only other theory that comes to mind is a compiler bug. Which compiler
are you using exactly?
Erm, well, gcc 2.5.8, but it turns out that's not the problem. It turned out
that the parser and scanner mentioned above had been regenerated, but
a recent bit of systems administration by our friendly folks here had
obscured that fact by changing all the timestamps.

initdb now runs fine.

Thanks for your time,

Tom Cook

--------------------------------------------------------------------------------------------------------------------
This e-mail (including attachments) is confidential information of Australian Submarine Corporation Pty Limited (ASC). It may also be legally privileged. Unauthorised use and disclosure is prohibited. ASC is not taken to have waived confidentiality or privilege if this e-mail was sent to you in error. If you have received it in error, please notify the sender promptly. While ASC takes steps to identify and eliminate viruses, it cannot confirm that this e-mail is free from them. You should scan this e-mail for viruses before it is used. The statements in this e-mail are those of the sender only, unless specifically stated to be those of ASC by someone with authority to do so.
Loading...