another pg database corruption?

Hi all,
I am using pg 7.3.4 on linuz red hat 7.3 and reiserFS.
After ~30 days error free work my pg stops.
I my log I found:
PANIC: open of /mnt/diske/skladdb/pg_clog/0D02 failed: No such file or
directory
LOG: statement: COPY public.a_sp (ids, ids_ma, ids_mp, ids_mr, ids_mpr,
ids_mpdt, ids_mpkt, smetkas, smetkaa, smetkad1, smetkad2, tip, vaji,
ime, imeeng, balans, opr, pp, prihrazh_razh, prihrazh_prih, ids_firma)
TO stdout;
LOG: server process (pid 1252) was terminated by signal 6
LOG: terminating any other active server processes
LOG: all server processes terminated; reinitializing shared memory and
semaphores
LOG: database system was interrupted at 2003-10-27 14:34:01 EET
LOG: checkpoint record is at 2/1C591C4C
LOG: redo record is at 2/1C591C4C; undo record is at 0/0; shutdown TRUE

LOG: next transaction id: 493496; next oid: 197060600
LOG: database system was not properly shut down; automatic recovery in
progress
LOG: ReadRecord: record with zero length at 2/1C591C8C
LOG: redo is not required
LOG: database system is ready
PANIC: open of /mnt/diske/skladdb/pg_clog/09FD failed: No such file or
directory
LOG: statement: COPY public.a_acc (ids, ids_firma, ids_debit,
ids_kredit, date_op, ids_vid_doc, ids_otdel, ids_papka, ids_papka1,
ids_papka2, parv_doc, doc, nomer, val, voborot, kurs, oborotlv, zab1,
zab2, kod1, kod2, kod3, addkod, pp, instime, modtime, ids_slu) TO
stdout;
LOG: server process (pid 1260) was terminated by signal 6
LOG: terminating any other active server processes
LOG: all server processes terminated; reinitializing shared memory and
semaphores
LOG: database system was interrupted at 2003-10-27 14:37:10 EET

How can I found the reason for this problem.
Also we try to use pg in production and to replace oracle, but it looks
very unstable with this corruption.
Exist any way to prevent pg from this error (for example real time
backup for changes or realtime replication?).
We are using pg from 3 y. and we was very happy, but in production it
looks not so stable.

many thanks,
ivan.