Re: Is my database now too big?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Scott Marlowe wrote:
...

Again, I'm kinda shooting in the dark here as you reveal more and more
what you are doing a little at a time.  A test case that can invoke
this failure would be most useful.
After seeing this today:
ERROR:  duplicate key violates unique constraint "ers_pkey"
ERROR:  duplicate key violates unique constraint "foo_pkey"
ERROR:  duplicate key violates unique constraint "foo_pkey"
ERROR:  duplicate key violates unique constraint "foo_pkey"
ERROR:  duplicate key violates unique constraint "foo_pkey"
ERROR:  duplicate key violates unique constraint "foo_pkey"
ERROR: could not open segment 1 of relation 1663/10793/2659 (target block 858862642): No such file or directory ERROR: could not open segment 1 of relation 1663/10793/2659 (target block 858862642): No such file or directory ERROR: could not open segment 1 of relation 1663/10793/2659 (target block 858862642): No such file or directory ERROR: could not open segment 1 of relation 1663/10793/2659 (target block 858862642): No such file or directory
...

...there was little or no activity during this time, apart from
some inserts, maybe some selects, etc.  Nothing that should
have caused this kind of upset.

There is a file that matches this:
-rw------- 1 postgres wheel 57344 Oct 14 22:57 /data/db/second/base/10793/2659
but it isn't in the directory where I moved most of the indexes to:
ls /data/index/ext/10793/
16390  16397  16399  16406  16407  16410  16414  16425  16434  16435

I don't know if the file numbers have any meaning?

But in addition, the list of tables (\dp) is now fubar'd.

I'm starting to wonder if it is a combination of:
- the operating system (NetBSD 4.99.20)
- the hardware (small HP box, not meant for hard work like this but shouldn't be impossible for it)
- the way pkgsrc compiles postgresql for NetBSD

I'm shying away from the hardware (or at least RAM/CPU) because I'd expect there to be some other kind kinds of faults show up, ultimately leading to a panic due to just random corruption of some kernel data structure. As it is, everything else seems to be functioning ok.

Darren


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux