Tom Lane wrote:
> Dave Page <dpage@pgadmin.org> writes:
> > Hmm, I think I misread Thom's question. The smgr API used to be far
> > more rigidly designed as I understand it, to allow the possibility of
> > having different storage engines (for example, maybe one that used raw
> > devices). I don't know that any other storage engines were ever
> > actually written though.
>
> There actually were two smgr storage modules in the code we inherited
> from Berkeley, and I think there were probably more at one time. But
> the smgr interface is *way* lower level than mysql's storage engines;
> there is not that much that you can do to affect the behavior of the DB
> by replacing an smgr module. I believe what they had in mind originally
> was to be able to drive different physical storage devices, using raw
> access instead of going through the filesystem. That decision was taken
> before everything of interest got unified under the Unix filesystem API.
> These days, if you needed to do what they had in mind, you'd be writing
> a kernel device driver instead. So smgr is pretty vestigial, and we've
> largely broken its API abstraction anyway by doing filesystem access
> directly in so many other places.
Yes, the second storage manager we had was for WORM drives, or more
accurately, stubs were left in our code for WORM drives.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ None of us is going to be here forever. +
