RE: bufmgr and smgr don't talk to each other, apparently

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

In response to

Responses

Browse pgsql-hackers by date

  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 ?