Переделал инфу
2016-04-27 13:28:46 IRKT LOG: database system was interrupted; last known up at 2016-04-27 13:16:51 IRKT
2016-04-27 13:28:46 IRKT LOG: invalid primary checkpoint record
2016-04-27 13:28:46 IRKT LOG: invalid secondary checkpoint link in control file
2016-04-27 13:28:46 IRKT PANIC: could not locate a valid checkpoint record
2016-04-27 13:28:46 IRKT LOG: startup process (PID 8912) exited with exit code 3
2016-04-27 13:28:46 IRKT LOG: aborting startup due to startup process failure

Из поисков в интернете попробовал выполнить pg_controldata

PostgreSQL\9.4.2-1.1C\bin>pg_controldata e:\pql

pg_control version number: 942
Catalog version number: 201409291
Database system identifier: 6254454928233336196
Database cluster state: in production
pg_control last modified: 27.04.2016 9:04:41
Latest checkpoint location: DC/223641B8
Prior checkpoint location: DC/1F301DA8
Latest checkpoint's REDO location: DC/213D1950
Latest checkpoint's REDO WAL file: 00000001000000DC00000021
Latest checkpoint's TimeLineID: 1
Latest checkpoint's PrevTimeLineID: 1
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID: 0/2148384
Latest checkpoint's NextOID: 4123902
Latest checkpoint's NextMultiXactId: 1
Latest checkpoint's NextMultiOffset: 0
Latest checkpoint's oldestXID: 668
Latest checkpoint's oldestXID's DB: 1
Latest checkpoint's oldestActiveXID: 0
Latest checkpoint's oldestMultiXid: 1
Latest checkpoint's oldestMulti's DB: 16402
Time of latest checkpoint: 27.04.2016 9:04:31
Fake LSN counter for unlogged rels: 0/1
Minimum recovery ending location: 0/0
Min recovery ending loc's timeline: 0
Backup start location: 0/0
Backup end location: 0/0
End-of-backup record required: no
Current wal_level setting: minimal
Current wal_log_hints setting: off
Current max_connections setting: 200
Current max_worker_processes setting: 8
Current max_prepared_xacts setting: 0
Current max_locks_per_xact setting: 64
Maximum data alignment: 8
Database block size: 8192
Blocks per segment of large relation: 131072
WAL block size: 8192
Bytes per WAL segment: 16777216
Maximum length of identifiers: 64
Maximum columns in an index: 32
Maximum size of a TOAST chunk: 1996
Size of a large-object chunk: 2048
Date/time type storage: 64-bit integers
Float4 argument passing: by value
Float8 argument passing: by reference
Data page checksum version: 0

Далее пробую почистить логи

PostgreSQL\9.4.2-1.1C\bin>pg_resetxlog -o 4123902 -x 2148384 -f e:\pql
pg_resetxlog: could not create pg_control file: File exists

Как устранить проблему с pg_resetxlog: could not create pg_control file: File exists?

Удалить существующий файл?

(0) Что значит "Переделал инфу"?

(2) закрыли преыдущую тему а с этим же сообщением не давал создать тему, пожтому добавил строчку

(1) Какой существующий?

(4) как вы думает что означает заклинание "File exists" ?

(5) файл существует!?

т.е. удалить файл pg_control?

(7) ну если совсем страшно, можно забекапить

после удаления файла то что делать?

После всех монипуляций получается завести службу постгри но пападаю на  PANIC:  could not open critical system index 2662

(10) http://postgresql.nabble.com/Server-continuously-enters-to-recovery-mode-td5802321.html
Последний пост.
И на всякий случай - (8)
Можно развернуть PostgrеSQL на другом компе, скопировать туда папку data и экспериментировать...

c:\Program Files\PostgreSQL\9.4.2-1.1C\bin>postgres --single -D E:\PQL postgres

2016-04-27 17:44:22 IRKT PANIC: could not open critical system index 2671

c:\Program Files\PostgreSQL\9.4.2-1.1C\bin>reindexdb --system postgres
reindexdb: could not connect to database postgres: PANIC:  could not open critical system index 2671

http://www.postgresql.org/docs/9.5/static/sql-reindex.html
Раздел Notes, в конце.
"Things are more difficult if you need to recover from corruption of an index on a system table. In this case it's important for the system to not have used any of the suspect indexes itself. (Indeed, in this sort of scenario you might find that server processes are crashing immediately at start-up, due to reliance on the corrupted indexes.) To recover safely, the server must be started with the -P option, which prevents it from using indexes for system catalog lookups.

One way to do this is to shut down the server and start a single-user PostgreSQL server with the -P option included on its command line. Then, REINDEX DATABASE, REINDEX SYSTEM, REINDEX TABLE, or REINDEX INDEX can be issued, depending on how much you want to reconstruct. If in doubt, use REINDEX SYSTEM to select reconstruction of all system indexes in the database. Then quit the single-user server session and restart the regular server. See the postgres reference page for more information about how to interact with the single-user server interface."
"-P     Ignore system indexes when reading system tables, but still update the indexes when modifying the tables. This is useful when recovering from damaged system indexes"