thanks Greg,
yes, we want SELinux in enforcing mode.
Thereby (and to ensure persistence) just chcon is the wrong way and
* semanage fcontext -a -t postgresql_t ''
* restorecon -vvFR
is much better ;-)
regards--GERD--
On Wednesday, August 04, 2010 07:56:56 am Greg Smith wrote:
> Gerd Koenig wrote
Gerd Koenig wrote:
thanks for the hint, yes, SELinux caused the troubles. It complained about
wrong filecontext while starting postgres via init-script.
Filecontext was: var_lib_t and it should be: postgresql_t
If you want to keep SELinux on, basically you have to relabel the
directory you
Hello Greg,
thanks for the hint, yes, SELinux caused the troubles. It complained about
wrong filecontext while starting postgres via init-script.
Filecontext was: var_lib_t and it should be: postgresql_t
regards...GERD
On Tuesday, August 03, 2010 11:54:45 pm Greg Smith wrote:
> Gerd Koenig
Gerd Koenig wrote:
Since even the init-script starts pg as user postgres I have no idea what
differs from init-script to direct call of pg_ctl as user postgres...?!?!
Do you have SELinux turned on? That can do weird stuff like this--the
init script will be running with restrictions the man
Hi again,
I just want to drop you an additional note. After several attempts of
debugging pg_standby is restoring the WAL files as expected, but I cannot
explain why...
First startup of postgres was with init-script provided by the rpm
installation (/etc/init.d/postgresql start as user root).
On Tue, 2010-08-03 at 22:37 +0200, Gerd Koenig wrote:
> Hello,
>
> we currently setup a standby database with archive_command sending the WALs
> from master to standby.
> This works as expected, but the standby database doesn't restore the WALs
> from
> the given directory in recovery.conf and
Hello,
we currently setup a standby database with archive_command sending the WALs
from master to standby.
This works as expected, but the standby database doesn't restore the WALs from
the given directory in recovery.conf and I have no idea why...
recovery.conf:
restore_comman
