1src/backend/storage/smgr/README 2 3Storage Managers 4================ 5 6In the original Berkeley Postgres system, there were several storage managers, 7of which only the "magnetic disk" manager remains. (At Berkeley there were 8also managers for the Sony WORM optical disk jukebox and persistent main 9memory, but these were never supported in any externally released Postgres, 10nor in any version of PostgreSQL.) The "magnetic disk" manager is itself 11seriously misnamed, because actually it supports any kind of device for 12which the operating system provides standard filesystem operations; which 13these days is pretty much everything of interest. However, we retain the 14notion of a storage manager switch in case anyone ever wants to reintroduce 15other kinds of storage managers. Removing the switch layer would save 16nothing noticeable anyway, since storage-access operations are surely far 17more expensive than one extra layer of C function calls. 18 19In Berkeley Postgres each relation was tagged with the ID of the storage 20manager to use for it. This is gone. It would be probably more reasonable 21to associate storage managers with tablespaces, should we ever re-introduce 22multiple storage managers into the system catalogs. 23 24The files in this directory, and their contents, are 25 26 smgr.c The storage manager switch dispatch code. The routines in 27 this file call the appropriate storage manager to do storage 28 accesses requested by higher-level code. smgr.c also manages 29 the file handle cache (SMgrRelation table). 30 31 md.c The "magnetic disk" storage manager, which is really just 32 an interface to the kernel's filesystem operations. 33 34 smgrtype.c Storage manager type -- maps string names to storage manager 35 IDs and provides simple comparison operators. This is the 36 regproc support for type "smgr" in the system catalogs. 37 (This is vestigial since no columns of type smgr exist 38 in the catalogs anymore.) 39 40Note that md.c in turn relies on src/backend/storage/file/fd.c. 41 42 43Relation Forks 44============== 45 46Since 8.4, a single smgr relation can be comprised of multiple physical 47files, called relation forks. This allows storing additional metadata like 48Free Space information in additional forks, which can be grown and truncated 49independently of the main data file, while still treating it all as a single 50physical relation in system catalogs. 51 52It is assumed that the main fork, fork number 0 or MAIN_FORKNUM, always 53exists. Fork numbers are assigned in src/include/common/relpath.h. 54Functions in smgr.c and md.c take an extra fork number argument, in addition 55to relfilenode and block number, to identify which relation fork you want to 56access. Since most code wants to access the main fork, a shortcut version of 57ReadBuffer that accesses MAIN_FORKNUM is provided in the buffer manager for 58convenience. 59