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
> On Feb 15, 2017, at 6:35 AM, Adrian Klaver <adrian.klaver@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.klaver@aklaver.com
