Crash and Socket Failure: 9-signalling Processes with Sudo

Question

The aim of the test is to simulate a serious fatal error, peeking into kernel due to the socket failure. It is good practise in cases such as crash-recovery.

9-signalling all postgres processes ignite errors immediately after the command:

$ psql
psql: could not connect to server: Connection refused
        Is the server running locally and accepting
        connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?

Questions

1. Does it have something to do with the levels, zero and three, of x86?
2. What did the 9-killing do to things such as kernel and fs?
3. What is wrong with the socket?
4. What did happen to files during the signaling, related to side effects?

Answer 1

Does it have something to do with the levels, zero and three, of x86?

No.

What did the 9-killing do to things such as kernel and fs?

Nothing - though the database files of postgresql might have been left in an inconsistent state.

Has the failure with reinstalling anything to do with side effects

No (?)

sending signal 9 to a process simply forces it to exit immediately. For a database server that can be a bit fatal if it was in the middle of altering the data files/storage - leaving them in an inconsistent state.

Sounds like you either havn't removed everything from your old postgresql installation, or you havn't configured the server properly after reinstalling it.

Answer 2

This more a Server Fault kind of question, but try running psql like this:

sudo -u postgres psql

When you install PostgreSQL, there's no user account created for your current user, so you'd have to create one.

That can be achieved like this (where masi is the wanted username):

sudo -u postgres createuser -sdrPE masi