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 по дате отправления:

Предыдущее
От: Stephane Bortzmeyer
Дата:
Сообщение: Re: [PORTS] Port Bug Report: buf_init.c does not compile (spin lock problem?)
Следующее
От: Unprivileged user
Дата:
Сообщение: Port Bug Report: plpsql - scan.l undefined symbols K_WHEN ...