Re: Postmaster won't -HUP

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jerry Lynde <jlynde(at)diligence(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Postmaster won't -HUP
Date: 2000-06-01 22:57:37
Message-ID: 28621.959900257@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Jerry Lynde <jlynde(at)diligence(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Bruce Momjian 2000-06-01 23:28:19 Re: PostgreSQL article in LinuxWorld
Previous Message Ross J. Reedstrom 2000-06-01 22:32:19 Re: Q: Truncated output