On 31/10/2009 4:32 PM, Karen Pease wrote:
> Sorry for the delay in responding, and thanks for your help.
By the way, you may also be able to learn some more using the 'blktrace'
tool. This gathers low-level data about what processes are performing
I/O on your system.
# mount -t debugfs none /sys/
Karen Pease wrote:
> Sorry for the delay in responding, and thanks for your help.
Sorry I have to keep on asking things. Unfortunately it's sometimes
quite hard to tell what part of a system is misbehaving, and it can
require the collection of quite a bit of diagnostic data :S
>From what I've see
Sorry for the delay in responding, and thanks for your help.
> You didn't actually request a backtrace (bt), so all it shows is the top
> stack frame. That doesn't tell us anything except that it's busy in a
> system call in the kernel.
For a newly-started psql process that locks as soon as the
On Tue, 2009-10-27 at 00:50 -0500, Karen Pease wrote:
> > OK, so there's nothing shrieklingly obviously wrong with what the
> > postmaster is up to. But what about the backend that's stopped
> > responding? Try connecting gdb to that "postgres" process once it's
> > stopped responding and get a bac
No -- one of the first things I do is shut off selinux, as it always is
a pain.
[r...@chmmr meme]# more /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# perm
> OK, so there's nothing shrieklingly obviously wrong with what the
> postmaster is up to. But what about the backend that's stopped
> responding? Try connecting gdb to that "postgres" process once it's
> stopped responding and get a backtrace from that.
>
Okay -- I started up a psql instance, wh
Karen Pease writes:
> Postgres is by default in /var/lib/pgsql. When / started running out of
> space, I moved it to /scratch and symlinked:
> lrwxrwxrwx 1 root root 15 2009-09-11 16:57 pgsql
> -> /scratch/pgsql//
Hmm, that could be a problem right there. Do you have SELinux runni
On 26/10/2009 5:28 PM, Karen Pease wrote:
> I did my best to follow the gdb instructions. I ran:
>
> gdb -p 2852
>
> Then connected entered the logging statements, then ran "cont", then
> ctrl-c'ed it a couple times. I got:
OK, so there's nothing shrieklingly obviously wrong with what the
post
I did my best to follow the gdb instructions. I ran:
gdb -p 2852
Then connected entered the logging statements, then ran "cont", then
ctrl-c'ed it a couple times. I got:
Program received signal SIGINT, Interrupt.
0x001e6416 in __kernel_vsyscall ()
(gdb) bt
#0 0x001e6416 in __kernel_vsyscall (
Karen Pease wrote:
> kill -9 does kill postmaster (or at least seems to). But I can't figure
> out a way to get it restarted without a reboot -- I don't know what I'm
> missing. The Fedora postgres restart scripts don't do the trick, and I
> couldn't get it to work with pg_ctl either.
It'd help
kill -9 does kill postmaster (or at least seems to). But I can't figure
out a way to get it restarted without a reboot -- I don't know what I'm
missing. The Fedora postgres restart scripts don't do the trick, and I
couldn't get it to work with pg_ctl either.
kill -9 doesn't work on the locked up
Karen Pease writes:
> It'll get through about three or four of them (out of hundreds) before
> it locks up. Now, before lockup, postmaster is very active. It shows
> up on top. The computer's hard drives clack nonstop. Etc. But once it
> locks up (without warning), all of that stop. Postmast
I've been dealing with a postgres (8.3.8.1.fc10) problem for a while
that has become quite frustrating in recent weeks. I have a set of
tables, one of which (geonames) is very large. This contains the
geonames geographical information database -- about 7 million records:
CREATE TABLE geonames (
13 matches
Mail list logo
