From: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Michael Simms" <grim(at)argh(dot)demon(dot)co(dot)uk>, <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | RE: [HACKERS] Frustration |
Date: | 1999-09-28 00:42:31 |
Message-ID: | 000101bf094a$58ecb140$2801007e@cadzone.tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: Monday, September 27, 1999 10:20 PM
> To: Hiroshi Inoue
> Cc: Michael Simms; pgsql-hackers(at)postgreSQL(dot)org
> Subject: Re: [HACKERS] Frustration
>
>
> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
> > 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.
>
> Oooh, good point. Shouldn't this be fixed? If we don't fix it, then
Yes,it's on TODO.
* spinlock stuck problem when elog(FATAL) and elog(ERROR) inside bufmgr
I would try to fix it.
> a disk I/O error will translate to an installation-wide shutdown and
> restart as soon as some backend tries to touch the locked page (as
> indeed was happening to Michael). That seems a tad extreme.
>
Regards.
Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 1999-09-28 01:21:15 | Re: [HACKERS] vacuum process size |
Previous Message | Tom Lane | 1999-09-28 00:06:32 | Re: [HACKERS] RI status report #1 |