> >Bison seems mandatory (Digital/Compaq's yacc makes errors)
> I believe that you can use Compaq's yacc using the '-N' parameter to
> increase the space available to build the LALR tables. I haven't checked
> it, thouth.
No, yacc ends up with some undefined symbols. So you really seem to need
Bison. But as Bison compiles out of the box, that is no big deal.
I've hit another problem when loading (largish) pl functions: at times
the backend processes seem to run out of stack, anyway I did get one
'ran out of stack' error message, and the default stack size is not
terrible big by default. I have no idea how to increase the stack size
for the backend processes. I know about ulimit, but I don't know how to
set it for the backend processes. I guess I could recompile the kernel,
but there must be an easier way.
I've had problems when reloading functions a few times (i.e. dropping
and creating), that the pg_proc table got corrupted. I think some of
them may have been too large and have breached the 8k tuple limit. I
split them into smaller functions and it seems to have happened less
often. At times shutting down the system, starting it up again and
vacuuming pg_proc would solve it, but mostly I had to drop the database
and start all over again. Anybody else had these problems?
In response to
pgsql-ports by date
|Next:||From: Unprivileged user||Date: 1999-06-18 14:18:29|
|Subject: Port Bug Report: plpsql - scan.l undefined symbols K_WHEN ...|
|Previous:||From: Stephane Bortzmeyer||Date: 1999-06-18 13:28:47|
|Subject: Re: [PORTS] Port Bug Report: buf_init.c does not compile (spin lock