I think I must have only done a reload on the live server as now I've
tried to restart the service and I've got exactly the same error, so
it's no longer a discrepancy between environments.
The script is actually one which came with the Gentoo package. I can
see it is using both $PGOPTS and $PGDATA, neither which are populated
with anything on either server. I've assigned $PGDATA to the database
cluster path but it still doesn't start. I've also checked
/etc/conf.d/postgresql-8.3 which contains correct settings.
Okay, so I've manually tried starting the server now and told it to
output any log to /tmp. This is telling me that the request for a
shared memory segment is higher than my kernel's SHMMAX parameter. My
bad, I've put my settings in incorrectly, and as it states in the
config file, changes to that setting require a restart. I've reset
all values to back to how they were and it is running again. I didn't
think my changes were that demanding, but obviously there were. I'll
have to look into it more.
Thanks for the suggestions.
Thom
On Thu, Oct 30, 2008 at 2:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Thom Brown" <thombrown@gmail.com> writes:
>> Actually I did "ps aux | grep post" just to cover all bases, but still
>> nothing.. except of course the grep itself.
>
> The overwhelming impression from here is of a seriously brain-dead
> startup script. It's spending all its effort on being chatty and none
> on actually dealing with unusual cases correctly :-(. Whose script
> is it anyway?
>
> My bet is that there's some discrepancy between what the script is
> expecting and what your intended configuration is. I'm not sure if
> the discrepancy is exactly the PID-file location or if it's more subtle
> than that, but anyway I'd suggest reading through that script carefully
> to see what it's actually doing.
>
> regards, tom lane
>