postgresql

mirror of https://git.postgresql.org/git/postgresql.git synced 2024-09-07 13:59:28 +02:00

History

Tom Lane b3817f5f77 Improve hash_create()'s API for some added robustness. 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 `a1b8aa1e4` (i.e., mistakenly omitting HASH_BLOBS). Also, when HASH_STRINGS is specified, insist that the keysize be more than 8 bytes. This is a heuristic, but it should catch accidental use of HASH_STRINGS for integer or pointer keys. (Nearly all existing use-cases set the keysize to NAMEDATALEN or more, so there's little reason to think this restriction should be problematic.) Tweak hash_create() to insist that the HASH_ELEM flag be set, and remove the defaults it had for keysize and entrysize. Since those defaults were undocumented and basically useless, no callers omitted HASH_ELEM anyway. Also, remove memset's zeroing the HASHCTL parameter struct from those callers that had one. This has never been really necessary, and while it wasn't a bad coding convention it was confusing that some callers did it and some did not. We might as well save a few cycles by standardizing on "not". Also improve the documentation for hash_create(). In passing, improve reinit.c's usage of a hash table by storing the key as a binary Oid rather than a string; and, since that's a temporary hash table, allocate it in CurrentMemoryContext for neatness. Discussion: https://postgr.es/m/590625.1607878171@sss.pgh.pa.us		2020-12-15 11:38:53 -05:00
..
Makefile	Split all OBJS style lines in makefiles into one-line-per-entry style.	2019-11-05 14:41:07 -08:00
md.c	Use truncate(2) where appropriate.	2020-12-01 15:42:22 +13:00
README	Drop the vestigial "smgr" type.	2019-03-07 15:44:04 +13:00
smgr.c	Improve hash_create()'s API for some added robustness.	2020-12-15 11:38:53 -05:00

README

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.