Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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.


Hiroshi Inoue

In response to


pgsql-hackers by date

Next:From: Hiroshi InoueDate: 2000-07-29 14:38:05
Subject: RE: Fwd: Postgres update
Previous:From: Karl DeBisschopDate: 2000-07-29 14:20:49
Subject: Re: Database Diagram Drawing Tools ?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group