RE: bufmgr and smgr don't talk to each other, apparently
От | Hiroshi Inoue |
---|---|
Тема | RE: bufmgr and smgr don't talk to each other, apparently |
Дата | |
Msg-id | EKEJJICOHDIEMGPNIFIJIECOCDAA.Inoue@tpf.co.jp обсуждение исходный текст |
Ответ на | bufmgr and smgr don't talk to each other, apparently (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: bufmgr and smgr don't talk to each other, apparently
|
Список | pgsql-hackers |
> -----Original Message----- > From: pgsql-hackers-owner@hub.org [mailto:pgsql-hackers-owner@hub.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
В списке pgsql-hackers по дате отправления: