From: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | RE: bufmgr and smgr don't talk to each other, apparently |
Date: | 2000-07-29 14:38:02 |
Message-ID: | EKEJJICOHDIEMGPNIFIJIECOCDAA.Inoue@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> -----Original Message-----
> From: pgsql-hackers-owner(at)hub(dot)org [mailto:pgsql-hackers-owner(at)hub(dot)org]On
> Behalf Of Tom Lane
>
> I have just noticed something that's been broken for a good long while
> (at least since 6.3): bufmgr.c expects that I/O errors will result in
> an SM_FAIL return code from the smgr.c routines, but smgr.c does no
> such thing: it does elog(ERROR) if it sees a failure. All of the
except smgropen(). It's not easy to return from mdxxx() in case of
errors. Fortunately I succeeded to return from mdopen() in 'file non-
existent' cases.
> "error handling" paths in bufmgr.c are dead code and have been since
> at least 6.3.
>
> It seems to me that we should either reduce smgr.c's elog()s to NOTICEs,
> or rip out all of the dead code in bufmgr.c. I'm inclined to the
> latter, since the former seems likely to create new bugs.
>
I also prefer the latter. Even though smgr returns SM_FAIL,md stuff
already calls elog(ERROR) in many places.
Regards.
Hiroshi Inoue
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Inoue | 2000-07-29 14:38:05 | RE: Fwd: Postgres update |
Previous Message | Karl DeBisschop | 2000-07-29 14:20:49 | Re: Database Diagram Drawing Tools ? |