I just finished installing the PGDG rpms on my second server. This one
is a single CPU Opteron with 2 SATA based RAID5 arrays. (Just to clear
things up, I know RAID5 is bad for postgres, but this is a storage
server that has postgres only as a backup for the main machine.)
The problem diesn'[t hap
Hi Tom,
> Hmm. That seems like a SELinux policy bug. It doesn't happen for me:
> the pid file is created with the same context the other files have.
I agree! I have the latest FC4 policy update. So I downloaded the
sources as the new one didn't solve the issue. The policy source has
no mention
"Just Someone" <[EMAIL PROTECTED]> writes:
> Some more clues that might help you see if there's a real problem, is
> that the /var/lib/pgsql/data/postmaster.pid file is created with the a
> SELinux context that's different from the rest. It is created with
> system_u:object_r:file_t while the rest
Hi Tom,
I looked into another system I have and after updating FC4 to the
latest and installing the latest from the PGDG srpms, I didn't have
this problem.
Tomorrow I'm going to do a similar test on another server that I have
to install Postgres on. I will report back with what I find on it. But
"Just Someone" <[EMAIL PROTECTED]> writes:
> I researched it a bit, and tried a few things, and discovered that the
> problem is in the init script at /etc/init.d/postgres users runuser
> instead of su on SELinux enabled systems. But for some reason it won't
> work this way. I manually reveted it t
Hi,
I know this isn't directly a postgres issue, but it might help a few
other users, so here goes.
I did an upgrade on my Fedora Core 4 system, and postgres (8.1.2 from
the postgres packages, not FC packages) stopped working because of
permission issues when trying to create postmaster.pid in th
