Question

Kill-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"?

Long-term Computer Science problem

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.

  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?
Was it helpful?

Solution

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

OTHER TIPS

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.

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

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top