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 > On Feb 15, 2017, at 6:35 AM, Adrian Klaver <adrian.kla...@aklaver.com> wrote: > > On 02/14/2017 08:47 PM, Shawn Thomas wrote: >> No it doesn’t matter if run with sudo, postgres or even root. Debian >> actually wraps the command and executes some some initial scripts with >> different privileges but ends up making sure that Postgres ends up >> running under the postgres user. I get the same output if run with sudo: >> >> sudo systemctl status postgresql@9.4-main.service >> <mailto:postgresql@9.4-main.service> -l >> Error: could not exec start -D /var/lib/postgresql/9.4/main -l >> /var/log/postgresql/postgresql-9.4-main.log -s -o -c >> config_file="/etc/postgresql/9.4/main/postgresql.conf” >> > > > So you are talking about: > > /etc/init.d/postgresql > > which then calls: > > /usr/share/postgresql-common/init.d-functions > > Or is there another setup on your system? > > Any relevant information in the system logs? > >> Thanks, though. >> >> -Shawn > > > -- > Adrian Klaver > adrian.kla...@aklaver.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
