Re: Postmaster won't -HUP - Mailing list pgsql-general

From Tom Lane
Subject Re: Postmaster won't -HUP
Date
Msg-id 28621.959900257@sss.pgh.pa.us
Whole thread Raw
In response to Re: Postmaster won't -HUP  (Jerry Lynde <jlynde@diligence.com>)
List pgsql-general
Jerry Lynde <jlynde@diligence.com> writes:
>     Thanks for the tip. I might indeed take that approach in the future,
> however that's not really the problem I'm trying to tackle right now.
> Indexing by Last Name is fine with me, currently. What's not working for me
> is the part where the dual pentium 500 machine with 256MB RAM goes into
> deep thought indefinitely for one simple hard-coded query.

Ah, sorry ... I've been seeing so many optimizer questions lately that
I tend to zero right in on anything that looks like a misoptimization
issue.

I'm not aware of any reason that a query such as you describe would
tend to hang up the machine.  It would be useful to know what you see
in "top" or some other monitoring program when the problem happens.
Is there just one backend process sucking all the CPU time?  More than
one?  Is the process(es) memory usage stable, or climbing?

An even more useful bit of info is a stack trace from a backend that's
suffering the problem: if you do a "kill -ABORT" on it you should get
a coredump and be able to backtrace with gdb.  (Note this will cause
a database system restart, ie all the other backends will commit
harakiri too, so I wouldn't advise doing it during normal usage of the
system.)

            regards, tom lane

pgsql-general by date:

Previous
From: "Ross J. Reedstrom"
Date:
Subject: Re: Q: Truncated output
Next
From: Bruce Momjian
Date:
Subject: Re: PostgreSQL article in LinuxWorld