> -----Original Message-----
> From: owner-pgsql-hackers@postgreSQL.org
> [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane
> Sent: Friday, September 24, 1999 11:27 PM
> To: Michael Simms
> Cc: pgsql-hackers@postgreSQL.org
> Subject: Re: [HACKERS] Frustration
>
>
> Michael Simms <grim@argh.demon.co.uk> writes:
> > Well, thanks to tom, I know what was wrong, and I have found
> the problem,
> > or one of them at least...
> > FATAL: s_lock(0c9ef824) at bufmgr.c:1106, stuck spinlock. Aborting.
> > Okee, that segment of code is, well, its some deep down internals that
> > are as clear as mud to me.
>
> Hmph. Apparently, some backend was waiting for some other backend to
> finish reading a page in or writing it out, and gave up after deciding
> it had waited an unreasonable amount of time (~ 1 minute, which does
> seem plenty long enough). Probably, the I/O did in fact finish, but
> the waiting backend didn't get the word for some reason.
>
[snip]
>
> Another likely explanation is that there's something wrong in
> bufmgr.c's logic for setting and releasing the io_in_progress lock ---
> but a quick look doesn't show any obvious error, and I would have
> thought we'd have found out about any such problem long since.
> Since we're not being buried in reports of stuck-spinlock errors,
> I'm guessing there is some platform-specific problem on your machine.
> No good ideas what it is if it isn't a spinlock failure.
>
Different from other spinlocks,io_in_progress spinlock is a per bufpage
spinlock and ProcReleaseSpins() doesn't release the spinlock.
If an error(in md.c in most cases) occured while holding the spinlock
,the spinlock would necessarily freeze.
Michael Simms saysERROR: cannot read block 641 of server
occured before the spinlock stuck abort.
Probably it is an original cause of the spinlock freeze.
However I don't understand the following status of his machine.
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
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp