Re: [HACKERS] Installation procedure.

Поиск
Список
Период
Сортировка
От Thomas Lockhart
Тема Re: [HACKERS] Installation procedure.
Дата
Msg-id 37A51161.55ECF14B@alumni.caltech.edu
обсуждение исходный текст
Ответ на [HACKERS] Installation procedure.  ("J. Michael Roberts" <mirobert@cs.indiana.edu>)
Ответы Re: [HACKERS] Installation procedure.  ("J. Michael Roberts" <mirobert@cs.indiana.edu>)
Re: [HACKERS] Installation procedure.  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> You people are harsh.

Ooh, a compliment. We live for those... ;)

> - initdb complained that it couldn't find a user.  I gave it -u postgres.

This is the only report of this I can remember (others might remind me
otherwise, but...). The best I can tell you somehow didn't have a USER
environment variable or mucked around with accounts between building
software and trying to initdb. There are several messages from initdb
with similar wording but with different diagnostics so you would need
to send the actual text or look in the initdb source code yourself
(src/bin/initdb/initdb.sh).

> - I needed to install flex (no surprise) -- the instructions are quite
>   explicit, but, well, wrong: flex depends on bison.  So you have to get
>   and compile bison first.  Also, the GNU FTP server has "redisorganized"
>   their file structure, so the very detailed FTP instructions for getting
>   flex are also outdated.

Thanks. Can you give a suggestion for a more helpful phrasing for
this, or a better choice of content?

> - Being only halfway a sysadmin, I was a little worried about making a
>   postgres "superuser".  I just made a postgres user and didn't worry
>   about the super part, and it seems to work.  Am I missing a point?

Only sort of. The "postgres superuser" is a normal user as far as the
OS is concerned, but is a superuser as far as the Postgres
installation is concerned. Ya done good.

> - The aforementioned shared memory problem was distressing.  Thank God
>   somebody else had just encountered it.  Is there any better way to
>   trap for that?  Should the default number of backends be made something
>   less than 32 so that the "common setting" of 1 meg will be safe?  Am I
>   being too wimpy?

This is the first release where the shared memory size was actually
being calculated correctly. The numbers used pretty much match the
theoretical (but incorrectly calculated) maximum limits in previous
releases, but the calculated number is bigger and a few OSes seem to
cough. Your OS is being wimpy imho, but the workaround is pretty easy.

Do you have a specific suggestion for a change here in the docs?
Probably no need to change the build procedure, but perhaps a warning
about possible startup problems?

Have fun with the new toy...
                   - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "J. Michael Roberts"
Дата:
Сообщение: [HACKERS] Installation procedure.
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] IPC Memory problem with Postmaster on BSDi 4.x