I'm working on postgresql code (server side). I installed a version from source code following the official tutorial: http://www.postgresql.org/docs/8.4/interactive/install-short.html

I did same modification on code, so I need to install again postgresql, but this time my version.

I renamed the /usr/local/pgsql/ in /usr/local/pgsql2/ and I did:

make distclean
sudo make install
sudo mkdir /usr/local/pgsql/data
sudo chown darkcoffeelinux /usr/local/pgsql/data

until now everything went well, but with the command

/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data/

I got this error:

The files belonging to this database system will be owned by user "darkcoffeelinux".
This user must also own the server process.

The database cluster will be initialized with locale en_US.UTF-8.
The default database encoding has accordingly been set to UTF8.
The default text search configuration will be set to "english".

fixing permissions on existing directory /usr/local/pgsql/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 24MB
creating configuration files ... ok
creating template1 database in /usr/local/pgsql/data/base/1 ... ok
initializing pg_authid ... Segmentation fault (core dumped)
child process exited with exit code 139
initdb: removing contents of data directory "/usr/local/pgsql/data"

Additional information: I'm using kubuntu, postgresql 8.4.15

  • 1
    Why are you working on such an outdated version? But this question is better asked on the Postgres hacker mailing list: postgresql.org/community/lists Feb 10 '13 at 8:35
  • Because i'm continuing a research project. Thank you for the link.
    – DarkCoffee
    Feb 10 '13 at 9:28

I think the permissions are correct because otherwise you wouldn't have gotten here.

My guess is that a modification you have made has caused the problem. This is particularly the case given that it is a segmentation fault. What you really need to do is look at the call stack at the time the core was dumped and see if you can isolate where in the code this is happening, and then back track to see what modifications you have made may have caused this. Given that you have modified the code, the first step is to check and see if you can reproduce as kgrittn says, but I am willing to bet that this will only show up with your modified code.

The next step is likely to be to run initdb inside a debugger and review the conditions at time of crash. At this point standard C debugging practices are really your best bet.

  • Thank you for your answer, I solved commenting my code and I found the error.
    – DarkCoffee
    Feb 20 '13 at 23:40

initdb and the server process itself must be run as the same OS user which owns the data directory. Don't forget to set permissions for that directory to only allow that user access (chmod 700).

Regarding the segmentation fault -- can you cause it with an unmodified version of PostgreSQL, or is this perhaps a result of bug in some customization you've done? Have you been able to get a core dump for it?

  • Thank you for your answer. I think that the permissions are set well. How can I get a core dump?
    – DarkCoffee
    Feb 10 '13 at 23:42
  • To get a core dump in Linux (which is one of your tags), you should run ulimit -c unlimited in the session or script which is starting the executable which is getting the segmentation fault. It looks like this setting is in effect, since it says "Segmentation fault (core dumped)". You can examine the back-trace and values of variables in gdb if you specify the core file when you start it. For that to be useful, you must have built with debug info, and it sometimes helps to reduce the optimization level of code.
    – kgrittn
    Feb 18 '13 at 20:30
  • Thank you. I solved commenting my code and I found the error.
    – DarkCoffee
    Feb 20 '13 at 23:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.