Tom Lane wrote: > Dave Page <dpage@xxxxxxxxxxx> 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@xxxxxxxxxx> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
