Thread: 7.4.1 Server Not Starting?
Hello all, I sure hope someone can help me out as I'm having the worst time trying to get this upgraded server running. I just upgraded to 7.4.1 (running on FreeBSD, upgraded through the ports collection if it means anything to anyone). To make a long story short, the server doesn't appear to be starting. I tried the normal start up script of course, and even running pg_ctl manually as the database superuser. I've even gone so far as to: postmaster -D /usr/local/pgsql/data That was also run as the database superuser. Unfortunately it doesn't produce anything, it immediately runs and exits with no error. At this point I'd be happy with just an error message! Any ideas? Greg
Gregory Wood <gwood@ewebengine.com> writes:
> ... I've even gone so far as to:
> postmaster -D /usr/local/pgsql/data
> That was also run as the database superuser. Unfortunately it doesn't
> produce anything, it immediately runs and exits with no error. At this
> point I'd be happy with just an error message!
[blink] It definitely shouldn't exit without an error message.
One thought that comes to mind is that you might have configured
postgresql.conf to report errors only to syslog and not to stderr.
If so, look in the system logs, or undo that change and try the manual
startup again.
If that's not it, are you game to get out the debugger? Exiting
without a message is a bug-that-needs-fixed, in my book.
regards, tom lane
Yeah, made me blink too. But you nailed it on the head... looking in postgresql.conf shows me that syslog = 2, which means no standard out. Seems that the behavior between the port for 7.3 and 7.4 has changed and now they log to syslog by default. Now to figure out why syslog doesn't appear to be logging anything... I also found the source of the error: I had previously (7.3 again) set max_fsm_relations = 10000. Apparently 7.4 doesn't like that too much. Bumping that back to 1000 seems to do the trick. Thank you once again for your late night help! Greg Tom Lane wrote: > Gregory Wood <gwood@ewebengine.com> writes: > >>... I've even gone so far as to: >>postmaster -D /usr/local/pgsql/data >>That was also run as the database superuser. Unfortunately it doesn't >>produce anything, it immediately runs and exits with no error. At this >>point I'd be happy with just an error message! > > > [blink] It definitely shouldn't exit without an error message. > > One thought that comes to mind is that you might have configured > postgresql.conf to report errors only to syslog and not to stderr. > If so, look in the system logs, or undo that change and try the manual > startup again. > > If that's not it, are you game to get out the debugger? Exiting > without a message is a bug-that-needs-fixed, in my book. > > regards, tom lane
Gregory Wood <gwood@ewebengine.com> writes:
> Yeah, made me blink too. But you nailed it on the head... looking in
> postgresql.conf shows me that syslog = 2, which means no standard out.
> Seems that the behavior between the port for 7.3 and 7.4 has changed and
> now they log to syslog by default. Now to figure out why syslog doesn't
> appear to be logging anything...
It's quite likely that the syslog daemon is configured to drop PG
messages instead of logging them. This would be a rather unfortunate
combination of default behaviors, however --- suggest griping to the
respective package maintainers that they need to get on the same page.
> I also found the source of the error: I had previously (7.3 again) set
> max_fsm_relations = 10000. Apparently 7.4 doesn't like that too much.
> Bumping that back to 1000 seems to do the trick.
Hmm, maybe that's pushing our shared-memory request just beyond the
kernel's SHMMAX? If so, again it'd be an unfortunate combination of
default settings. max_fsm_relations = 10000 shouldn't take all that
much more memory ...
regards, tom lane
> It's quite likely that the syslog daemon is configured to drop PG > messages instead of logging them. This would be a rather unfortunate > combination of default behaviors, however --- suggest griping to the > respective package maintainers that they need to get on the same page. It's logging to the local0 facility which isn't set up by default... I'm surprised that the catch all /var/log/messages didn't catch it, but I'm up hours late and can't remember what that defaulted to at the moment. I'll try to remember to send that suggestion to the port maintainer. >>I also found the source of the error: I had previously (7.3 again) set >>max_fsm_relations = 10000. Apparently 7.4 doesn't like that too much. >>Bumping that back to 1000 seems to do the trick. > > Hmm, maybe that's pushing our shared-memory request just beyond the > kernel's SHMMAX? If so, again it'd be an unfortunate combination of > default settings. max_fsm_relations = 10000 shouldn't take all that > much more memory ... Well, here are the relevant (?) settings I changed: max_connections = 256 shared_buffers = 8192 max_fsm_relations = 10000 max_fsm_pages = 100000 sort_mem = 8192 vacuum_mem = 32768 Perhaps a combination of those settings is what did it? Greg
Gregory Wood <gwood@ewebengine.com> writes:
> Perhaps a combination of those settings is what did it?
Maybe --- what was the failure message exactly, once you got it?
Also, if you hand-edited these settings, it's fair to ask what
the port package defaults are ...
regards, tom lane
>>Perhaps a combination of those settings is what did it? > > Maybe --- what was the failure message exactly, once you got it? Managed to fix it before I got any errors actually. Simple enough to re-break it however: FATAL: max_fsm_pages must exceed max_fsm_relations * 16 Looks like I was 60000 short on my 100000 max_fsm_pages setting for a max_fsm_relations of 10000. Anyway, the error message was a good one, I just couldn't get to it last night. > Also, if you hand-edited these settings, it's fair to ask what > the port package defaults are ... Sounds fair to me, IIRC: max_connections = 100 shared_buffers = 1000 max_fsm_relations = 1000 max_fsm_pages = 20000 sort_mem = 1024 vacuum_mem = 8192 Greg