Re: [PORTS] Port Bug Report: buf_init.c does not compile (spin lockproblem?)
От | Adriaan Joubert |
---|---|
Тема | Re: [PORTS] Port Bug Report: buf_init.c does not compile (spin lockproblem?) |
Дата | |
Msg-id | 376A4C12.36D5AB15@albourne.com обсуждение исходный текст |
Ответ на | Re: [PORTS] Port Bug Report: buf_init.c does not compile (spin lock problem?) ("Pedro J. Lobo" <pjlobo@euitt.upm.es>) |
Список | 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 по дате отправления: