7.4.1 Server Not Starting?

[Gregory Wood]

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

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Tom Lane]

Gregory Wood <gw***@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

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

[Gregory Wood]

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 <gw***@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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Tom Lane]

Gregory Wood <gw***@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

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

[Gregory Wood]

> 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

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[Tom Lane]

Gregory Wood <gw***@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

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Gregory Wood]

>>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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster