OK, thanks to some probing by Hiroshi, and by the fact that it became
utterly blatantly obvious, I can state as a fact that postgresql was NOT
responsible for the crashes I was seeing last night.
I woke up this morning, intent on finding SOME solution, and I found this
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda3 1109780 704964 347461 67% /
/dev/hda1 33149 6140 25297 20% /boot
/dev/hdc1 9515145 3248272 5773207 36% /home
/dev/hdb1 402852 154144 227903 40% /tmp
/dev/sda1 30356106785018642307 43892061535609608 0 100% /var/lib/pgsql
Now, I thought to myself, either my 9.2GB drive has become the size of a
small country, or I have a problem.
Much probing has revealed to me that the nice adapted U2W scsi card that I
installed, has problems under Linux SMP kernels.
As such, I wave the penguin of shame at Adaptec for shoddy drivers. And
I declare that I once again find postgres warm and fuzzy and huggable {:-)
~Michael
ps. Before the problem became too obvious, Hiroshi sent me the following.
It may be useful, I have no idea what it does {:-))
------------------------------------
Disk full error while writing a block may be one of the cause.
As far as I see,error on block write isn't handled correctly in md.c.
The following patch may help you.
However I didn't test the patch at all.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
*** storage/smgr/md.c.orig Fri Sep 24 15:01:29 1999
--- storage/smgr/md.c Fri Sep 24 18:07:31 1999
***************
*** 243,248 ****
--- 243,255 ---- if ((pos = FileSeek(v->mdfd_vfd, 0L, SEEK_END)) < 0) return SM_FAIL;
+ if (pos % BLCKSZ != 0)
+ {
+ pos = BLCKSZ * (pos / BLCKSZ);
+ if (FileSeek(v->mdfd_vfd, pos, SEEK_SET) != pos)
+ return SM_FAIL;
+ }
+ if (FileWrite(v->mdfd_vfd, buffer, BLCKSZ) != BLCKSZ) return SM_FAIL;
***************
*** 1060,1065 **** { long len;
! len = FileSeek(file, 0L, SEEK_END) - 1;
! return (BlockNumber) ((len < 0) ? 0 : 1 + len / blcksz); }
--- 1067,1072 ---- { long len;
! len = FileSeek(file, 0L, SEEK_END);
! return (BlockNumber) (len / blcksz); }