backend/parser compile prob

Patrick Welche <prlw1@newn.cam.ac.uk> writes:

I'm getting far too many errors while trying to compile gram.c in the
backend/parser, that I must be missing something.

I think you need to force gram.c to be regenerated. Try removing it
(and parse.h too) before building.

% cvs diff src/backend/parser/gram.c

gram.c is not in CVS. I'm surprised you didn't get an error from that.
(I get "cvs server: I know nothing about gram.c".)

regards, tom lane

On Tue, Jul 15, 2003 at 11:21:51AM -0400, Tom Lane wrote:

Patrick Welche <prlw1@newn.cam.ac.uk> writes:

I'm getting far too many errors while trying to compile gram.c in the
backend/parser, that I must be missing something.

I think you need to force gram.c to be regenerated. Try removing it
(and parse.h too) before building.

% cvs diff src/backend/parser/gram.c

gram.c is not in CVS. I'm surprised you didn't get an error from that.
(I get "cvs server: I know nothing about gram.c".)

Ah: Attic:

% cvs status gram.c
===================================================================
File: gram.c Status: Up-to-date

Working revision: 2.90
Repository revision: 2.90 /projects/cvsroot/pgsql-server/src/backend/parser/Attic/gram.c,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)

hmm...

rm gram.c parse.h scan.c

gmake[3]: Leaving directory `/usr/src/local/pgsql/src/port'
gmake -C parser parse.h
gmake[3]: Entering directory `/usr/src/local/pgsql/src/backend/parser'
bison -y -d gram.y
mv -f y.tab.c ./gram.c
mv -f y.tab.h ./parse.h
gmake[3]: Leaving directory `/usr/src/local/pgsql/src/backend/parser'
prereqdir=`cd parser/ >/dev/null && pwd` && \
cd ../../src/include/parser/ && rm -f parse.h && \
ln -s "$prereqdir/parse.h" .
gmake -C access all
gmake[3]: Entering directory `/usr/src/local/pgsql/src/backend/access'
...
gmake[3]: Nothing to be done for `all'.
gmake[3]: Leaving directory `/usr/src/local/pgsql/src/backend/catalog'
gmake -C parser all
gmake[3]: Entering directory `/usr/src/local/pgsql/src/backend/parser'
/usr/bin/flex -CF -o'scan.c' scan.l
gcc -O2 -pipe -g -Wall -Wmissing-prototypes -Wmissing-declarations -I. -I../../../src/include -c -o gram.o gram.c
In file included from gram.y:7990:
scan.c:121: parse error before string constant
scan.c:247: parse error before string constant
scan.c:250: parse error before string constant
scan.c:251: parse error before string constant
...

What string constant?! Will try again later...

Cheers,

Patrick

Patrick Welche <prlw1@newn.cam.ac.uk> writes:

/usr/bin/flex -CF -o'scan.c' scan.l
gcc -O2 -pipe -g -Wall -Wmissing-prototypes -Wmissing-declarations -I. -I../../../src/include -c -o gram.o gram.c
In file included from gram.y:7990:
scan.c:121: parse error before string constant
scan.c:247: parse error before string constant
scan.c:250: parse error before string constant
scan.c:251: parse error before string constant
...

What string constant?! Will try again later...

Which flex version are you using? You need 2.5.4 --- the most recent
versions have broken backwards compatibility :-(. I'm not sure what the
symptom looks like, though.

regards, tom lane

On Tue, Jul 15, 2003 at 12:42:45PM -0400, Tom Lane wrote:

Patrick Welche <prlw1@newn.cam.ac.uk> writes:

...

What string constant?! Will try again later...

Which flex version are you using? You need 2.5.4 --- the most recent
versions have broken backwards compatibility :-(. I'm not sure what the
symptom looks like, though.

Answer is: a broken flex 2.5.4. There were some commits to NetBSD flex to
use bounded strings. Using 13th July flex source builds a happy PostgreSQL.
Now to track down which bit broke - anyway, not a PostgreSQL problem :-)

Cheers,

Patrick
======================
All 91 tests passed.
======================
NetBSD-1.6U/i386

Answer is: a broken flex 2.5.4. There were some commits to NetBSD flex to
use bounded strings. Using 13th July flex source builds a happy PostgreSQL.
Now to track down which bit broke - anyway, not a PostgreSQL problem :-)

could you try usr.bin/lex/initscan.c revision 1.16?

itojun

On Wed, Jul 16, 2003 at 11:58:01PM +0900, itojun@iijlab.net wrote:

could you try lex/scan.l 1.13 i just committed?

Yes, that fixed it!

Cheers,

Patrick

could you try lex/scan.l 1.13 i just committed?

Yes, that fixed it!

tnx for reporting!

itojun

Can somebody clarify for me the requirement for the SHMSEG kernel parameter,
please.

The Postgres doc says:

SHMSEG - Maximum number of shared memory segments per process
only 1 segment is needed, but the default is much higher

I was trying to calculate the kernel parameters for running a number
of Postgres servers on Solaris, and something did not work.

Having Postgres running I executed ipcs. It shows that while Postgres is
taking
only one segment, the number of attachments is 7. This I think refers to the
number
of processes spawned by postmaster at that time.

Solaris docs describe SHMSEG as
"Limit on the number of shared memory segments
that any one process can create"

Now run this:
sysdef | grep SHMSEG
-> 50 max attached shm segments per process (SHMSEG)

I suppose there's a distinction between "can create" and "can attach to".
Looks like the manual and output of sysdef are not very consistent.

I am worried that maybe (on Solaris) SHMSEG should be set with respect
to number of connections, rather than number of servers.

Thank you,
Mike.