I'm getting far too many errors while trying to compile gram.c in the
backend/parser, that I must be missing something.. Story so far
gmake distclean
cvs update
configure --enable-debug --enable-cassert
gmake

gmake[3]: Entering directory `/usr/src/local/pgsql/src/backend/parser'
gcc -O2 -pipe -g -Wall -Wmissing-prototypes -Wmissing-declarations -I. -I../../../src/include   -c -o gram.o gram.c
gram.y:105: parse error before `Attr'
gram.y:105: warning: no semicolon at end of struct or union
gram.y:109: parse error before `*'
gram.y:109: warning: type defaults to `int' in declaration of `param'
gram.y:109: warning: data definition has no type or storage class
...

GNU Make version 3.79.1

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

In other words, I'm not even regenerating gram.c with
bison (GNU Bison) 1.875
flex version 2.5.4

Thoughts?

Cheers,

Patrick

Tue, 15 Jul 2003 13:47:35 +0100
Patrick Welche <prlw1@newn.cam.ac.uk>
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

Tue, 15 Jul 2003 11:21:51 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: backend/parser compile prob 
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

Tue, 15 Jul 2003 17:17:41 +0100
Patrick Welche <prlw1@newn.cam.ac.uk>
Re: backend/parser compile prob
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

Tue, 15 Jul 2003 12:42:45 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: backend/parser compile prob 
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

Wed, 16 Jul 2003 10:07:55 +0100
Patrick Welche <prlw1@newn.cam.ac.uk>
Re: backend/parser compile prob
>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

Wed, 16 Jul 2003 18:10:11 +0900
itojun@iijlab.net
Re: backend/parser compile prob 
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.



Wed, 16 Jul 2003 15:03:37 -0400
Michael Brusser <michael@synchronicity.com>
SHMSEG definition