Re: [PORTS] Port Bug Report: buf_init.c does not compile (spin lockproblem?) - Mailing list pgsql-ports

From Adriaan Joubert
Subject Re: [PORTS] Port Bug Report: buf_init.c does not compile (spin lockproblem?)
Date
Msg-id 376A4C12.36D5AB15@albourne.com
Whole thread Raw
In response to Re: [PORTS] Port Bug Report: buf_init.c does not compile (spin lock problem?)  ("Pedro J. Lobo" <pjlobo@euitt.upm.es>)
List pgsql-ports
> >
> >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?

Adriaan

pgsql-ports by date:

Previous
From: Stephane Bortzmeyer
Date:
Subject: Re: [PORTS] Port Bug Report: buf_init.c does not compile (spin lock problem?)
Next
From: Unprivileged user
Date:
Subject: Port Bug Report: plpsql - scan.l undefined symbols K_WHEN ...