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 functionality in a perl script so that the PG process is integrated with systemd. I really wish they hadn’t, and it’s part of 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@xxxxxxxxxxxxxxxxx> 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/main directory. 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-install Postgres 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@xxxxxxxxxxx
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
