Solaris, Postgresql and Problems

Errol Neal <errol.neal@enhtech.com> writes:

After making this change, and increasing the max number of buffers to
128 and the max number of connections to 64, I rebooted my
system. Things come up fine, Postgres seems happy, but shortly after
the Postgres server dies or terminates with nothing in logs as to WHY
it terminates and it keeps doing so even after I revert back to my
original config. The only things that remedies the problem of the
server dying without any apparent notice is if I revert back to my
original /etc/system file.. Does anybody have any experience with
these issues? All I am trying to do is get a few more connections out
of my system. I could sure use someone's help. Do I need to re-compile
postgresql?

Why don't you run the server under 'truss' to see what is killing it?
It it probably dumping core, or trying to, since there is nothing in
the logs--check your 'ulimit -c' settings and see if there are any
core files hanging around in $PGDATA.

-Doug

At 10:02 AM 7/25/2003 -0400, you wrote:

Errol Neal <errol.neal@enhtech.com> writes:

After making this change, and increasing the max number of buffers to
128 and the max number of connections to 64, I rebooted my
system. Things come up fine, Postgres seems happy, but shortly after
the Postgres server dies or terminates with nothing in logs as to WHY
it terminates and it keeps doing so even after I revert back to my
original config. The only things that remedies the problem of the
server dying without any apparent notice is if I revert back to my
original /etc/system file.. Does anybody have any experience with
these issues? All I am trying to do is get a few more connections out
of my system. I could sure use someone's help. Do I need to re-compile
postgresql?

Why don't you run the server under 'truss' to see what is killing it?
It it probably dumping core, or trying to, since there is nothing in
the logs--check your 'ulimit -c' settings and see if there are any
core files hanging around in $PGDATA.

-Doug

Actually Doug, it is not even "dying". I used the incorrect word. It is
shutting down... Here is a log entry:

LOG: fast shutdown request
LOG: shutting down
LOG: database system is shut down
LOG: database system was shut down at 2003-07-25 10:54:57 EDT
LOG: checkpoint record is at 0/909710
LOG: redo record is at 0/909710; undo record is at 0/0; shutdown TRUE
LOG: next transaction id: 7898764; next oid: 49906
LOG: database system is ready
LOG: fast shutdown request
LOG: shutting down
LOG: database system is shut down

That is a few seconds after the system comes back up with even the default
amount of connections after I put this in my /etc/system file:

* POSTGRESQL SETUP 07/24/03
* optimised for 512 connections
*set shmsys:shminfo_shmmax=0x2000000 postgres docs max
set shmsys:shminfo_shmmin=1
*set shmsys:shminfo_shmmni=256 wasn't enough for 512 pgsql connections
set shmsys:shminfo_shmmni=512
set shmsys:shminfo_shmseg=256
set semsys:seminfo_semmap=256
set semsys:seminfo_semmni=512
set semsys:seminfo_semmsl=32
* set semsys:seminfo_semmns=512 wasn't enough for 512 pgsql connections
set semsys:seminfo_semmns=1024

*15/5/03
set shmsys:shminfo_shmmax=939524096

The interesting thing is that only my postgres server is having problems
with these settings. I am running sendmail and a few other apps that I've
compiled on this system.
Why is the server just shutting down? It does not exit with an error or
anything like that.
Now, I will be the first to admit that I am not a Sun/Solaris genius!
Actually, I am more like a novice in some respects. However, I know unix
administration. My point in saying that
is I don't know if those settings are appropriate for my hardware and memory.

Again, I would very much appreciate any help and assistance.

Errol

Errol Neal, Systems/Network Administrator
eneal@enhtech.com
Enhanced Technologies Inc.
http://www.enhtech.com
703-924-0301 or 800-368-3249
703-924-0302 Fax

Errol Neal <errol.neal@enhtech.com> writes:

At 10:02 AM 7/25/2003 -0400, you wrote:

Why don't you run the server under 'truss' to see what is killing it?
It it probably dumping core, or trying to, since there is nothing in
the logs--check your 'ulimit -c' settings and see if there are any
core files hanging around in $PGDATA.

Actually Doug, it is not even "dying". I used the incorrect word. It
is shutting down... Here is a log entry:

LOG: fast shutdown request

This means *something* is sending a SIGTERM to the postmaster. Again,
try running it under 'truss' and see what it's doing right before it
gets the signal.

-Doug

On Friday, July 25, 2003, at 10:15 AM, Doug McNaught wrote:

This means *something* is sending a SIGTERM to the postmaster. Again,
try running it under 'truss' and see what it's doing right before it
gets the signal.

Also, make sure you are starting it in a way that you can _see_ the
error. Use something like

postmaster -D /usr/local/pgsql/data

If you are using a startup script or something similar, you may not see
the error in your terminal.

I often have this problem after changing system settings.

Cory 'G' Watson
http://www.loggerithim.org

Errol Neal wrote:

Actually Doug, it is not even "dying". I used the incorrect word. It
is shutting down... Here is a log entry:

LOG: fast shutdown request
LOG: shutting down
LOG: database system is shut down
LOG: database system was shut down at 2003-07-25 10:54:57 EDT
LOG: checkpoint record is at 0/909710
LOG: redo record is at 0/909710; undo record is at 0/0; shutdown TRUE
LOG: next transaction id: 7898764; next oid: 49906
LOG: database system is ready
LOG: fast shutdown request
LOG: shutting down
LOG: database system is shut down

I've ever met problem alike in solaris 8, and it turns out as Tom suggested
that it's the ctrl-c (SIGTERM) causes the problem. If I'm not guessed worng,
may be you are using the command 'tail -f yourlogfile' to see your log after
the server start up, and then ctrl-c to quit the 'tail', but the signal
would send
to postmaster also and cause it shutdown.

If so, I'll recommend the precedure below to circumvent the problem:

1, login postgresql superuser accound;
2, start postgresql (nohup pg_ctl start blah, blah);
3, exit login
4, re-login with postgresql superuser and 'tail -f yourlogfile' to
monitor it.

but I still searching the reason why solaris would act like that

Don't know if it helps.

regards

Laser

I don't remember if I mentioned this or not on this thread, but Solaris
pfiles and other similar tools sometimes send wierd signals to processes.
You might check your cron tabs to see if something like this is being run
on a regular basis.

Jon

On Fri, 25 Jul 2003, Weiping He wrote:

At 11:34 PM 7/25/2003 +0800, Weiping He wrote:

Errol Neal wrote:

Actually Doug, it is not even "dying". I used the incorrect word. It is
shutting down... Here is a log entry:

LOG: fast shutdown request
LOG: shutting down
LOG: database system is shut down
LOG: database system was shut down at 2003-07-25 10:54:57 EDT
LOG: checkpoint record is at 0/909710
LOG: redo record is at 0/909710; undo record is at 0/0; shutdown TRUE
LOG: next transaction id: 7898764; next oid: 49906
LOG: database system is ready
LOG: fast shutdown request
LOG: shutting down
LOG: database system is shut down

I've ever met problem alike in solaris 8, and it turns out as Tom suggested
that it's the ctrl-c (SIGTERM) causes the problem. If I'm not guessed worng,
may be you are using the command 'tail -f yourlogfile' to see your log after
the server start up, and then ctrl-c to quit the 'tail', but the signal
would send
to postmaster also and cause it shutdown.

If so, I'll recommend the precedure below to circumvent the problem:

1, login postgresql superuser accound;
2, start postgresql (nohup pg_ctl start blah, blah);
3, exit login
4, re-login with postgresql superuser and 'tail -f yourlogfile' to monitor it.

but I still searching the reason why solaris would act like that

Don't know if it helps.

regards

Laser

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

That is amazing.. It does it every time. But the funny thing is, it does
not do that using the default /etc/system settings. I tail log files all
the time and exit them with a ctrl-c. Postgres never interprets that as a
signal for it to exit... neither do any of my other processes running..

Errol Neal, Systems/Network Administrator
eneal@enhtech.com
Enhanced Technologies Inc.
http://www.enhtech.com
703-924-0301 or 800-368-3249
703-924-0302 Fax

On Fri, 2003-07-25 at 11:35, Errol Neal wrote:

At 11:34 PM 7/25/2003 +0800, Weiping He wrote:

Errol Neal wrote:

[snip]

That is amazing.. It does it every time. But the funny thing is, it does
not do that using the default /etc/system settings. I tail log files all
the time and exit them with a ctrl-c. Postgres never interprets that as a
signal for it to exit... neither do any of my other processes running..

Or you could dump that chicken-poop Slowlaris and go with The Real
Man's OS: Windows 2k3!!!!!

Whaaa hahahahahahahahahahah! ROTFLMAO <snort><gurgle><choke><die>

-- 
+-----------------------------------------------------------------+
| Ron Johnson, Jr.        Home: ron.l.johnson@cox.net             |
| Jefferson, LA  USA                                              |
|                                                                 |
| "I'm not a vegetarian because I love animals, I'm a vegetarian  |
|  because I hate vegetables!"                                    |
|    unknown                                                      |
+-----------------------------------------------------------------+