mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-09-07 13:59:28 +02:00
Invent a new flag bit HASH_STRINGS to specify C-string hashing, which
was formerly the default; and add assertions insisting that exactly
one of the bits HASH_STRINGS, HASH_BLOBS, and HASH_FUNCTION be set.
This is in hopes of preventing recurrences of the type of oversight
fixed in commit
|
||
---|---|---|
.. | ||
Makefile | ||
md.c | ||
README | ||
smgr.c |
src/backend/storage/smgr/README Storage Managers ================ In the original Berkeley Postgres system, there were several storage managers, of which only the "magnetic disk" manager remains. (At Berkeley there were also managers for the Sony WORM optical disk jukebox and persistent main memory, but these were never supported in any externally released Postgres, nor in any version of PostgreSQL.) The "magnetic disk" manager is itself seriously misnamed, because actually it supports any kind of device for which the operating system provides standard filesystem operations; which these days is pretty much everything of interest. However, we retain the notion of a storage manager switch in case anyone ever wants to reintroduce other kinds of storage managers. Removing the switch layer would save nothing noticeable anyway, since storage-access operations are surely far more expensive than one extra layer of C function calls. In Berkeley Postgres each relation was tagged with the ID of the storage manager to use for it. This is gone. It would be probably more reasonable to associate storage managers with tablespaces, should we ever re-introduce multiple storage managers into the system catalogs. The files in this directory, and their contents, are smgr.c The storage manager switch dispatch code. The routines in this file call the appropriate storage manager to do storage accesses requested by higher-level code. smgr.c also manages the file handle cache (SMgrRelation table). md.c The "magnetic disk" storage manager, which is really just an interface to the kernel's filesystem operations. Note that md.c in turn relies on src/backend/storage/file/fd.c. Relation Forks ============== Since 8.4, a single smgr relation can be comprised of multiple physical files, called relation forks. This allows storing additional metadata like Free Space information in additional forks, which can be grown and truncated independently of the main data file, while still treating it all as a single physical relation in system catalogs. It is assumed that the main fork, fork number 0 or MAIN_FORKNUM, always exists. Fork numbers are assigned in src/include/common/relpath.h. Functions in smgr.c and md.c take an extra fork number argument, in addition to relfilenode and block number, to identify which relation fork you want to access. Since most code wants to access the main fork, a shortcut version of ReadBuffer that accesses MAIN_FORKNUM is provided in the buffer manager for convenience.