Re: [GENERAL] Can't restart Postgres - Mailing list pgsql-general

On 02/15/2017 09:03 AM, Shawn Thomas wrote:
> /usr/lib/postgresql/9.4/bin/pg_ctl: No such file or directory
>
> postgres@pangaea:/usr/lib/postgresql/9.4/bin$ ls -al
>   total 4008
>   drwxr-xr-x 2 root root    4096 Feb  9 16:17 .
>   drwxr-xr-x 3 root root    4096 Feb  9 16:17 ..
>   -rwxr-xr-x 1 root root   68128 Nov 16 06:53 clusterdb
>   -rwxr-xr-x 1 root root   68192 Nov 16 06:53 createdb
>   -rwxr-xr-x 1 root root   63920 Nov 16 06:53 createlang
>   -rwxr-xr-x 1 root root   72672 Nov 16 06:53 createuser
>   -rwxr-xr-x 1 root root   63936 Nov 16 06:53 dropdb
>   -rwxr-xr-x 1 root root   63920 Nov 16 06:53 droplang
>   -rwxr-xr-x 1 root root   63904 Nov 16 06:53 dropuser
>   -rwxr-xr-x 1 root root   68416 Nov 16 06:53 pg_basebackup
>   -rwxr-xr-x 1 root root  351904 Nov 16 06:53 pg_dump
>   -rwxr-xr-x 1 root root 2186504 Nov 16 06:53 pg_dumpall
>   -rwxr-xr-x 1 root root   30992 Nov 16 06:53 pg_isready
>   -rwxr-xr-x 1 root root   47600 Nov 16 06:53 pg_receivexlog
>   -rwxr-xr-x 1 root root   51928 Nov 16 06:53 pg_recvlogical
>   -rwxr-xr-x 1 root root  154944 Nov 16 06:53 pg_restore
>   -rwxr-xr-x 1 root root  515320 Nov 16 06:53 psql
>   -rwxr-xr-x 1 root root   68160 Nov 16 06:53 reindexdb
>   -rwxr-xr-x 1 root root   72384 Nov 16 06:53 vacuumdb
>
> As I mentioned, this Debian package removes pg_ctl from the bin directory and instead attempts to wrap the pg_ctl
functionalityin a perl script so that the PG process is integrated with systemd.  I really wish they hadn’t, and it’s
partof the reason I’m where I’m at. 

Ubuntu uses the same setup and I see it, see below.

The Perl script just redirects commands to the correct version of
Postgres and uses that versions binaries.


aklaver@arkansas:~$ uname -a
Linux arkansas 4.8.6-x86_64-linode78 #1 SMP Tue Nov 1 14:51:21 EDT 2016
x86_64 x86_64 x86_64 GNU/Linux
aklaver@arkansas:~$ l /usr/lib/postgresql/9.4/bin/
total 8388
drwxr-xr-x 2 root root    4096 Feb  9 07:24 ./
drwxr-xr-x 4 root root    4096 Sep 29  2015 ../
-rwxr-xr-x 1 root root   68096 Feb  8 07:04 clusterdb*
-rwxr-xr-x 1 root root   68160 Feb  8 07:04 createdb*
-rwxr-xr-x 1 root root   63888 Feb  8 07:04 createlang*
-rwxr-xr-x 1 root root   72640 Feb  8 07:04 createuser*
-rwxr-xr-x 1 root root   63904 Feb  8 07:04 dropdb*
-rwxr-xr-x 1 root root   63888 Feb  8 07:04 droplang*
-rwxr-xr-x 1 root root   63872 Feb  8 07:04 dropuser*
-rwxr-xr-x 1 root root  114296 Feb  8 07:04 initdb*
-rwxr-xr-x 1 root root   26624 Feb  8 07:04 oid2name*
-rwxr-xr-x 1 root root   18432 Feb  8 07:04 pg_archivecleanup*
-rwxr-xr-x 1 root root   68416 Feb  8 07:04 pg_basebackup*
-rwxr-xr-x 1 root root   64600 Feb  8 07:04 pgbench*
-rwxr-xr-x 1 root root   30792 Feb  8 07:04 pg_config*
-rwxr-xr-x 1 root root   30720 Feb  8 07:04 pg_controldata*
-rwxr-xr-x 1 root root   43320 Feb  8 07:04 pg_ctl*
-rwxr-xr-x 1 root root  355968 Feb  8 07:04 pg_dump*
-rwxr-xr-x 1 root root   89320 Feb  8 07:04 pg_dumpall*
-rwxr-xr-x 1 root root   30960 Feb  8 07:04 pg_isready*
-rwxr-xr-x 1 root root   47568 Feb  8 07:04 pg_receivexlog*
-rwxr-xr-x 1 root root   51928 Feb  8 07:04 pg_recvlogical*
-rwxr-xr-x 1 root root   38920 Feb  8 07:04 pg_resetxlog*
-rwxr-xr-x 1 root root  154912 Feb  8 07:04 pg_restore*
-rwxr-xr-x 1 root root   22536 Feb  8 07:04 pg_standby*
-rwxr-xr-x 1 root root   22648 Feb  8 07:04 pg_test_fsync*
-rwxr-xr-x 1 root root   14416 Feb  8 07:04 pg_test_timing*
-rwxr-xr-x 1 root root  113168 Feb  8 07:04 pg_upgrade*
-rwxr-xr-x 1 root root   51672 Feb  8 07:04 pg_xlogdump*
-rwxr-xr-x 1 root root 5993920 Feb  8 07:04 postgres*
lrwxrwxrwx 1 root root       8 Feb  8 07:04 postmaster -> postgres*
-rwxr-xr-x 1 root root  519384 Feb  8 07:04 psql*
-rwxr-xr-x 1 root root   68128 Feb  8 07:04 reindexdb*
-rwxr-xr-x 1 root root   72352 Feb  8 07:04 vacuumdb*
-rwxr-xr-x 1 root root   22528 Feb  8 07:04 vacuumlo*

>
> -Shawn
>
>
>
>> On Feb 15, 2017, at 8:49 AM, Joshua D. Drake <jd@commandprompt.com> wrote:
>>
>> On 02/15/2017 08:35 AM, Shawn Thomas wrote:
>>> Yes, that’s the correct sequence of scripts.  And no there’s not anything really helpful in the system logs.
>>>
>>> I’m thinking that at this point I need to approach this problem as more of a disaster recovery.  There was a full
pg_dumpall file that was deleted and cannot be recovered so I need to recover the data from the
/var/lib/postgresql/9.4/maindirectory.  I believe this is called a file level recovery.  I assume I need to use a fully
functional,same version PG (on another machine?) to create a full dump of the data directory.  Once I have this I can
re-installPostgres on the initial server and read the databases back into it. 
>>>
>>> Any advice on how to best go about this?  The official documentation seems a bit thin:
>>>
>>> https://www.postgresql.org/docs/9.4/static/backup-file.html
>>>
>>> I’ve only worked with normal (pg_dump, pg_dumpall) backups in the past.
>>
>> Shawn
>>
>> As the postgres user:
>>
>> /usr/lib/postgresql/9.4/bin/pg_ctl -D /var/lib/postgresql/9.4/main start
>>
>> What returns?
>>
>> Sincerely,
>>
>> JD
>>
>>
>> --
>> Command Prompt, Inc.                  http://the.postgres.company/
>>                        +1-503-667-4564
>> PostgreSQL Centered full stack support, consulting and development.
>> Everyone appreciates your honesty, until you are honest with them.
>> Unless otherwise stated, opinions are my own.
>


--
Adrian Klaver
adrian.klaver@aklaver.com