Re: Postmaster won't -HUP
От | Tom Lane |
---|---|
Тема | Re: Postmaster won't -HUP |
Дата | |
Msg-id | 28621.959900257@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Postmaster won't -HUP (Jerry Lynde <jlynde@diligence.com>) |
Список | 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 по дате отправления: