Database corruption in RH 6.2/prepackaged PG

Saku Airila (saku(at)bitblit(dot)fi) reports a bug with a severity of 1
The lower the number the more severe it is.

Short Description
Database corruption in RH 6.2/prepackaged PG

Long Description
Random database corruption. The system I'm running has ~10 databases
online on a single server without other load. Sometimes one of the
databases corrupts itself beyond repair. I have vacuumdb and pg_dump
running nightly for cleaning the db and making a backup.

Postgres version:
PostgreSQL 6.5.3 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.66

System:
Red Hat Linux release 6.2 (Zoot)
Kernel 2.2.14-5.0 on an i686
650 Mhz AMD Duron, MSI K7T Pro mainboard, 64 MB + 100 MB swap,
ASUS 53C896 U2 SCSI, IBM DDYS-T09170N 9 GB disk,
D-Link DFE500TX (DEC tulip) ethernet.

Problem description:
The nightly cron jobs return me the following message:
----
dumpClasses(): command failed. Explanation from backend: 'pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
'.
----
I get the following message to the syslog wher trying to dump or
vacuum the db manually:
----
Jan 13 16:32:38 db kernel: Unable to handle kernel paging request at virtual add
ress 0003000b
Jan 13 16:32:38 db kernel: current->tss.cr3 = 00e99000, %cr3 = 00e99000
Jan 13 16:32:38 db kernel: *pde = 00000000
Jan 13 16:32:38 db kernel: Oops: 0000
Jan 13 16:32:38 db kernel: CPU: 0
Jan 13 16:32:38 db kernel: EIP: 0010:[update_vm_cache_conditional+111/284]
Jan 13 16:32:38 db kernel: EFLAGS: 00010206
Jan 13 16:32:38 db kernel: eax: 00000000 ebx: 00030003 ecx: c2250220 edx:
00001050
Jan 13 16:32:38 db kernel: esi: 00000000 edi: 00001000 ebp: 0002e000 esp:
c0e9be9c
Jan 13 16:32:38 db kernel: ds: 0018 es: 0018 ss: 0018
Jan 13 16:32:38 db kernel: Process postmaster (pid: 28997, process nr: 33, stack
page=c0e9b000)
Jan 13 16:32:38 db kernel: Stack: 0002e000 c099a000 c3f30000 0c225022 c013bf19 c
2250220 0002e000 c099a000
Jan 13 16:32:38 db kernel: 00001000 40251c40 c33570e0 ffffffea c225026c 0
0002000 c1a8d7e0 c1a8d7e0
Jan 13 16:32:38 db kernel: c1a8d7e0 0002e000 00000000 c0e9bf08 00000000 0
0000000 c33efa00 00000000
Jan 13 16:32:38 db kernel: Call Trace: [ext2_file_write+1042/1559] [refile_buffe
r+82/178] [__brelse+19/82] [ext2_update_inode+825/840] [sys_recv+30/35] [sys_wri
te+214/248] [ext2_file_write+0/1559]
Jan 13 16:32:38 db kernel: [system_call+52/56]
Jan 13 16:32:38 db kernel: Code: 39 4b 08 75 f0 39 6b 0c 75 eb ff 43 14 b8 02 00
00 00 0f ab

I don't know if this is really a PostgreSQL problem or a Linux problem, but I'm quite sure the harware itself is ok.

If more information is needed, I'm happy to send the database dump,
altough the system being a confidential production system I need to
make sure the dump will not be disclosed to any third parties.

Thanks,

Saku Airila, saku(at)bitblit(dot)fi
Systems Engineer, Bitblit Oy, Helsinki, Finland

Sample Code

No file was uploaded with this report