Eu estou usando Fedora 15com PostgreSQL 9.1.4. O Fedora travou recentemente, após o qual:

Uma tentativa de iniciar o servidor PostgreSQL:

service postgresql-9.1 start

dá

Starting postgresql-9.1 (via systemctl):  Job failed. See system logs and 'systemctl status' for details.
                                                       [FAILED]

Embora, o servidor inicie normalmente quando inicio o servidor pela primeira vez após a reinicialização do sistema .
Mas, uma tentativa de usar psqlfornece este erro:

psql: could not connect to server: No such file or directory
    Is the server running locally and accepting
    connections on Unix domain socket "/tmp/.s.PGSQL.5432"?

.s.PGSQL.5432O arquivo não está presente em nenhum lugar do sistema. A locate .s.PGSQL.5432não produz nada.

O log do sistema possui o seguinte:

Aug 14 17:31:58 localhost systemd[1]: postgresql-9.1.service: control process exited, code=exited status=1
Aug 14 17:31:58 localhost systemd[1]: Unit postgresql-9.1.service entered failed state.

UMA

systemctl status postgresql-9.1.service

dá

postgresql-9.1.service - SYSV: PostgreSQL database server.
          Loaded: loaded (/etc/rc.d/init.d/postgresql-9.1)
      Active: failed since Tue, 14 Aug 2012 17:31:58 +0530; 58s ago
     Process: 2811 ExecStop=/etc/rc.d/init.d/postgresql-9.1 stop (code=exited, status=1/FAILURE)
     Process: 12423 ExecStart=/etc/rc.d/init.d/postgresql-9.1 start (code=exited, status=1/FAILURE)
    Main PID: 2551 (code=exited, status=1/FAILURE)
      CGroup: name=systemd:/system/postgresql-9.1.service

Eu não havia alterado a configuração padrão do fsync, então acho que foi definido como on. Eu estou em um disco rígido. O disco rígido travou.

Falha no disco rígido

A falha do disco rígido resultou na execução de um manual fsckem um prompt e não em GUI. Com ele reparando gazilhões de inodes etc. Depois disso, reiniciei o sistema com um Ctrl+ Alt+ Delete.

O log do PostgreSQL possui:

LOG:  database system was interrupted; last known up at 2012-08-14 17:31:57 IST
LOG:  database system was not properly shut down; automatic recovery in progress
LOG:  record with zero length at 0/41A4E58
LOG:  redo is not required
FATAL:  could not access status of transaction 1
DETAIL:  Could not open file "pg_multixact/offsets/0000": No such file or directory.
LOG:  startup process (PID 13016) exited with exit code 1
LOG:  aborting startup due to startup process failure

Atualizar

A tentativa de iniciar o servidor após fazer uma cópia do /var/lib/pgsqldiretório no nível do sistema de arquivos e executar ./pg_resetxlog -f /var/lib/pgsql/9.1/data/com o resultado xlog -f /var/lib/pgsql/9.1/data/ainda gera:

LOG:  database system was interrupted; last known up at 2012-08-14 18:46:36 IST
LOG:  database system was not properly shut down; automatic recovery in progress
LOG:  record with zero length at 0/6000078
LOG:  redo is not required
FATAL:  could not access status of transaction 1
DETAIL:  Could not open file "pg_multixact/offsets/0000": No such file or directory.
LOG:  startup process (PID 13766) exited with exit code 1
LOG:  aborting startup due to startup process failure

A resposta real estará nos logs do PostgreSQL, em /var/lib/pgsql/data/pg_log.

No entanto, antes de executar qualquer ação: é vital que você faça uma cópia no nível do sistema de arquivos do seu banco de dados antes de tentar reparar se algum dos seus dados é valioso para você . Veja http://wiki.postgresql.org/wiki/Corruption . Você deve copiar o diretório de dados inteiro. Por /var/lib/pgsql/datapadrão, no Fedora , mas verifique se a instalação está correta.

Com base nos logs que você postou, você certamente tem algum grau de corrupção no banco de dados. O armazenamento em que o banco de dados está (o disco rígido ou o sistema de arquivos) provavelmente está danificado. Faça uma cópia AGORA e coloque-a em um disco rígido ou sistema diferente .

Somente depois de fazer uma cópia completa no nível do sistema de arquivos do diretório de dados, tente usar pg_resetxlog para limpar os logs de transações danificados e iniciar o banco de dados. Mesmo que inicie, é altamente provável que esteja corrompido; você deve pg_dumprefazê- initdblo e restaurar o dump para a nova instância.

Se você ainda não conseguir iniciá-lo depois de um pg_resetxlog, publique um log atualizado da tentativa de inicialização após o resetxlog. É possível que você precise iniciar a página no modo autônomo com:

sudo -u postgres postgres --single -D /var/lib/pgsql/data -P -f i postgres

Se isso funcionar, fornecendo um backend>prompt, tente novamente depois de substituir o último "postgres" pelo nome do banco de dados ao qual você deseja se conectar. Você deve poder SELECT, COPYdados de tabelas, etc.

Se isso não funcionar, ou seja, você não pode iniciar um back-end autônomo, provavelmente é hora de restaurar os backups - já que você é sensato o suficiente para tê-los. Se alguém mais lendo isso estiver na mesma posição, entre em contato com um consultor experiente do PostgreSQL para ver se eles podem recuperar dados do seu banco de dados. Esteja preparado para pagar por seu tempo e experiência.

Seu sistema de arquivos provavelmente está danificado

A gravidade do dano na instalação do PostgreSQL sugere que todo o sistema de arquivos provavelmente está danificado. Você pode considerar restaurar o sistema inteiro a partir de um backup ou reinstalá-lo.

Eu não confiaria neste sistema de arquivos fsckou não fsck.

Teste SMART sua unidade

Eu também recomendo que você SMARTverifique o disco rígido com o smartctlsmartmontools; assumindo /dev/hdaque seria assim smartctl -d ata -a /dev/sda | less. Procure por um teste de integridade com falha uncorrectable_sectors, uma alta taxa de erros de leitura, um número real_alocado_de_setor_ maior que 2 ou 3 ou um número_alterial atual diferente de zero. Corra smartctl -d ata -t long /dev/sdapara executar um autoteste não destrutivo no seu disco rígido; não interromperá o funcionamento normal do sistema. Quando o tempo estimado tiver passado, execute smartctl -d ata /dev/sdanovamente e verifique o log de autoteste para ver se ele passou.

Se algo parecer menos do que perfeito, substitua a unidade.

No futuro, considere automatizar esse teste via smartdpara aviso prévio de falhas na unidade.

(O conteúdo desta postagem foi obsoleto por atualizações da pergunta. Se você estiver solucionando um problema semelhante, consulte o histórico de edições desta resposta).