| | That's ok, you work with Dan Moschuk right?
|
| He's my bitch. :-)
|
| And as such, I've donated him to do neat things with postgres' C++ interface
| (for whatever reason, he's of the less-enlightened opinion that C++ shouldn't
| be dragged out into the backy
| > Sorry about that email. I was trying to forward your comments to a friend
| > and due to a lack of sleep I just typed "R" in pine. Doh!
|
| That's ok, you work with Dan Moschuk right?
He's my bitch. :-)
And as such, I've donated him to do neat things wit
| > This happens fairly regularly. I assume exit code 26 is used to dictate
| > that a specific error has occured.
| >
| > The database is a decent size (~3M records) with about 4 indexes.
|
| What version of postgresql? Tom Lane recently fixed some severe problems
| with vacuum and heavily u
| > Server process (pid 13361) exited with status 26 at Fri Nov 3 17:49:44 2000
|
| What's signal 26 on your system? (Look in /usr/include/signal.h or
| /usr/include/signum.h or /usr/include/sys/signal.h)
dan@spirit:/home/dan grep 26 /usr/include/sys/signal.h
#define SIGVTALRM 26 /
Server process (pid 13361) exited with status 26 at Fri Nov 3 17:49:44 2000
Terminating any active server processes...
NOTICE: Message from PostgreSQL backend:
The Postmaster has informed me that some other backend died abnormally and
possibly corrupted shared memory.
I have ro
I'm trying to track down a source of great slowdown on our database, and
I seem to have become stuck.
If I issue the command...
c2net=> UPDATE url SET last_hit = 971456105 WHERE memid = 1;
This is all I see of it in my -d 2 window log.
query: UPDATE url SET last_hit = 971456105 WHERE memid =
Running postgres in -d 2 mode is a little frustrating on a server that
processes as little as 10 queries a second. Can we not add getpid() or
something to that code so that we might track which output belongs to
which server a little easier?
Thanks,
-Dan
--
Man is a rational animal who alway
This time in the client library...
(gdb) bt
#0 0xff215dd0 in _poll ()
#1 0xff1ce79c in select ()
#2 0xff08b164 in select ()
#3 0xff338ec0 in PQgetResult (conn=0xa89c8) at fe-exec.c:1126
#4 0xff339168 in PQexec (conn=0xa89c8,
query=0xfe107b98 "UPDATE url SET
total_os='4963.98|135037.315
| I said:
| > BlockSig includes SIGUSR1.
|
| Oh, wait, I take that back. It's initialized that way, but then
| postmaster.c removes SIGUSR1 from the set.
|
| regards, tom lane
So, back to my initial question, why not make each postmaster SIG_IGN
SIGUSR1 after it receive
| Still, it's a mighty peculiar backtrace.
Indeed.
| After looking at postmaster.c, I see that the postmaster will issue
| SIGUSR1 to all remaining backends *each* time it sees a child exit
| with nonzero status. And it just so happens that quickdie() chooses
| to exit with exit(1) not exit(0)
| > Sparc solaris 2.7 with postgres 7.0.2
| > It seems to be reproducable, the server crashes on us at a rate of about
| > every few hours.
|
| That's a very bizarre backtrace. Why the multiple levels of recursive
| entry to the quickdie() signal handler? I wonder if you aren't looking
| at so
| % uname -sr
| SunOS 5.7
|
| from sys/signal.h:
|
| #define SIGUSR1 16 /* user defined signal 1 */
|
| Are you sure you don't have any application running amok sending
| signals to processes it shouldn't? Getting a superfolous signal
| seems out of place, this doesn't look like a crash
Sparc solaris 2.7 with postgres 7.0.2
It seems to be reproducable, the server crashes on us at a rate of about
every few hours.
Any ideas?
GNU gdb 4.17
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change i
13 matches
Mail list logo
