head	1.6;
access;
symbols
	REL9_0_0:1.6
	REL9_1_ALPHA1:1.6
	REL9_0_RC1:1.6
	REL9_0_BETA4:1.6
	REL9_0_STABLE:1.6.0.14
	REL9_0_BETA3:1.6
	REL9_0_BETA2:1.6
	REL7_4_29:1.1.1.1
	REL8_0_25:1.3
	REL8_1_21:1.3
	REL8_2_17:1.3
	REL8_3_11:1.3
	REL8_4_4:1.6
	REL9_0_BETA1:1.6
	REL9_0_ALPHA5_BRANCH:1.6.0.12
	REL9_0_ALPHA5:1.6
	REL7_4_28:1.1.1.1
	REL8_0_24:1.3
	REL8_1_20:1.3
	REL8_2_16:1.3
	REL8_3_10:1.3
	REL8_4_3:1.6
	REL9_0_ALPHA4:1.6
	REL9_0_ALPHA4_BRANCH:1.6.0.10
	REL8_5_ALPHA3:1.6
	REL8_5_ALPHA3_BRANCH:1.6.0.8
	REL7_4_27:1.1.1.1
	REL8_0_23:1.3
	REL8_1_19:1.3
	REL8_2_15:1.3
	REL8_3_9:1.3
	REL8_4_2:1.6
	REL8_5_ALPHA2:1.6
	REL8_5_ALPHA2_BRANCH:1.6.0.6
	REL7_4_26:1.1.1.1
	REL8_0_22:1.3
	REL8_1_18:1.3
	REL8_2_14:1.3
	REL8_3_8:1.3
	REL8_4_1:1.6
	REL8_5_ALPHA1:1.6
	REL8_5_ALPHA1_BRANCH:1.6.0.4
	REL8_4_STABLE:1.6.0.2
	REL8_4_0:1.6
	REL8_4_RC2:1.6
	REL8_4_RC1:1.6
	REL8_4_BETA2:1.6
	REL8_4_BETA1:1.6
	REL7_4_25:1.1.1.1
	REL8_0_21:1.3
	REL8_1_17:1.3
	REL8_2_13:1.3
	REL8_3_7:1.3
	REL7_4_24:1.1.1.1
	REL8_0_20:1.3
	REL8_1_16:1.3
	REL8_2_12:1.3
	REL8_3_6:1.3
	REL7_4_23:1.1.1.1
	REL8_0_19:1.3
	REL8_1_15:1.3
	REL8_2_11:1.3
	REL8_3_5:1.3
	REL7_4_22:1.1.1.1
	REL8_0_18:1.3
	REL8_1_14:1.3
	REL8_2_10:1.3
	REL8_3_4:1.3
	REL7_4_21:1.1.1.1
	REL8_0_17:1.3
	REL8_1_13:1.3
	REL8_2_9:1.3
	REL8_3_3:1.3
	REL7_4_20:1.1.1.1
	REL8_0_16:1.3
	REL8_1_12:1.3
	REL8_2_8:1.3
	REL8_3_2:1.3
	REL8_2_7:1.3
	REL8_3_1:1.3
	REL8_3_STABLE:1.3.0.10
	REL8_3_0:1.3
	REL8_3_RC2:1.3
	REL7_3_21:1.1.1.1
	REL7_4_19:1.1.1.1
	REL8_0_15:1.3
	REL8_1_11:1.3
	REL8_2_6:1.3
	REL8_3_RC1:1.3
	REL8_3_BETA4:1.3
	REL8_3_BETA3:1.3
	REL8_3_BETA2:1.3
	REL8_3_BETA1:1.3
	REL7_3_20:1.1.1.1
	REL7_4_18:1.1.1.1
	REL8_0_14:1.3
	REL8_1_10:1.3
	REL8_2_5:1.3
	REL7_3_19:1.1.1.1
	REL7_4_17:1.1.1.1
	REL8_0_13:1.3
	REL8_1_9:1.3
	REL8_2_4:1.3
	REL8_0_12:1.3
	REL8_1_8:1.3
	REL8_2_3:1.3
	REL7_3_18:1.1.1.1
	REL7_4_16:1.1.1.1
	REL8_0_11:1.3
	REL8_1_7:1.3
	REL8_2_2:1.3
	REL8_0_10:1.3
	REL8_1_6:1.3
	REL8_2_1:1.3
	REL7_4_15:1.1.1.1
	REL7_3_17:1.1.1.1
	REL8_2_STABLE:1.3.0.8
	REL8_2_0:1.3
	REL8_2_RC1:1.3
	REL8_2_BETA3:1.3
	REL8_2_BETA2:1.3
	REL8_1_5:1.3
	REL8_0_9:1.3
	REL7_4_14:1.1.1.1
	REL7_3_16:1.1.1.1
	REL8_2_BETA1:1.3
	REL7_3_15:1.1.1.1
	REL7_4_13:1.1.1.1
	REL8_0_8:1.3
	REL8_1_4:1.3
	REL7_3_14:1.1.1.1
	REL7_4_12:1.1.1.1
	REL8_0_7:1.3
	REL8_1_3:1.3
	REL7_3_13:1.1.1.1
	REL7_4_11:1.1.1.1
	REL8_0_6:1.3
	REL8_1_2:1.3
	REL7_3_12:1.1.1.1
	REL7_4_10:1.1.1.1
	REL8_0_5:1.3
	REL8_1_1:1.3
	REL8_1_STABLE:1.3.0.6
	REL8_1_0:1.3
	REL8_1_0RC1:1.3
	REL8_1_0BETA4:1.3
	REL8_1_0BETA3:1.3
	REL7_3_11:1.1.1.1
	REL7_4_9:1.1.1.1
	REL8_0_4:1.3
	REL8_1_0BETA2:1.3
	REL8_1_0BETA1:1.3
	REL7_2_8:1.1.1.1
	REL7_3_10:1.1.1.1
	REL7_4_8:1.1.1.1
	REL8_0_3:1.3
	REL8_0_2:1.3
	REL7_2_7:1.1.1.1
	REL7_3_9:1.1.1.1
	REL7_4_7:1.1.1.1
	REL8_0_1:1.3
	REL8_0_STABLE:1.3.0.4
	REL8_0_0:1.3.0.2
	REL8_0_0RC5:1.3
	REL8_0_0RC4:1.3
	REL8_0_0RC3:1.3
	REL8_0_0RC2:1.3
	REL8_0_0RC1:1.3
	REL8_0_0BETA5:1.3
	REL8_0_0BETA4:1.3
	REL7_4_6:1.1.1.1
	REL7_3_8:1.1.1.1
	REL7_2_6:1.1.1.1
	REL8_0_0BETA3:1.3
	REL8_0_0BETA2:1.3
	REL7_2_5:1.1.1.1
	REL7_4_5:1.1.1.1
	REL7_3_7:1.1.1.1
	REL7_4_4:1.1.1.1
	REL8_0_0BETA1:1.3
	REL7_4_3:1.1.1.1
	REL7_4_2:1.1.1.1
	REL7_3_6:1.1.1.1
	REL7_4_1:1.1.1.1
	REL7_3_5:1.1.1.1
	REL7_4:1.1.1.1
	REL7_4_RC2:1.1.1.1
	REL7_4_STABLE:1.1.1.1.0.20
	REL7_4_RC1:1.1.1.1
	REL7_4_BETA5:1.1.1.1
	REL7_4_BETA4:1.1.1.1
	REL7_4_BETA3:1.1.1.1
	REL7_4_BETA2:1.1.1.1
	WIN32_DEV:1.1.1.1.0.18
	REL7_4_BETA1:1.1.1.1
	REL7_3_4:1.1.1.1
	REL7_3_2:1.1.1.1
	REL7_2_4:1.1.1.1
	REL7_3_STABLE:1.1.1.1.0.16
	REL7_2_3:1.1.1.1
	REL7_2_STABLE:1.1.1.1.0.14
	REL7_2:1.1.1.1
	REL7_2_RC2:1.1.1.1
	REL7_2_RC1:1.1.1.1
	REL7_2_BETA5:1.1.1.1
	REL7_2_BETA4:1.1.1.1
	REL7_2_BETA3:1.1.1.1
	REL7_2_BETA2:1.1.1.1
	REL7_2_BETA1:1.1.1.1
	REL7_1_2:1.1.1.1
	REL7_1_STABLE:1.1.1.1.0.12
	REL7_1_BETA:1.1.1.1
	REL7_1_BETA3:1.1.1.1
	REL7_1_BETA2:1.1.1.1
	REL7_1:1.1.1.1
	REL7_0_PATCHES:1.1.1.1.0.10
	REL7_0:1.1.1.1
	REL6_5_PATCHES:1.1.1.1.0.8
	REL6_5:1.1.1.1
	REL6_4:1.1.1.1.0.6
	release-6-3:1.1.1.1
	REL2_0B:1.1.1.1.0.4
	REL2_0:1.1.1.1
	Release_2_0_0:1.1.1.1
	Release_1_0_3:1.1.1.1.0.2
	Release_2_0:1.1.1.1
	Release_1_0_2:1.1.1.1
	PG95-1_01:1.1.1.1
	PG95_DIST:1.1.1;
locks; strict;
comment	@# @;


1.6
date	2008.08.11.11.05.11;	author heikki;	state Exp;
branches;
next	1.5;

1.5
date	2008.03.21.13.23.28;	author momjian;	state Exp;
branches;
next	1.4;

1.4
date	2008.03.20.17.55.15;	author momjian;	state Exp;
branches;
next	1.3;

1.3
date	2004.02.10.01.55.26;	author tgl;	state Exp;
branches;
next	1.2;

1.2
date	2003.11.29.19.51.57;	author pgsql;	state Exp;
branches;
next	1.1;

1.1
date	96.07.09.06.21.59;	author scrappy;	state Exp;
branches
	1.1.1.1;
next	;

1.1.1.1
date	96.07.09.06.21.59;	author scrappy;	state Exp;
branches;
next	;


desc
@@


1.6
log
@Introduce the concept of relation forks. An smgr relation can now consist
of multiple forks, and each fork can be created and grown separately.

The bulk of this patch is about changing the smgr API to include an extra
ForkNumber argument in every smgr function. Also, smgrscheduleunlink and
smgrdounlink no longer implicitly call smgrclose, because other forks might
still exist after unlinking one. The callers of those functions have been
modified to call smgrclose instead.

This patch in itself doesn't have any user-visible effect, but provides the
infrastructure needed for upcoming patches. The additional forks envisioned
are a rewritten FSM implementation that doesn't rely on a fixed-size shared
memory block, and a visibility map to allow skipping portions of a table in
VACUUM that have no dead tuples.
@
text
@$PostgreSQL: pgsql/src/backend/storage/smgr/README,v 1.5 2008/03/21 13:23:28 momjian Exp $

Storage Manager
===============

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.)  However, we retain the notion of a storage
manager switch in case anyone wants to reintroduce other kinds of storage
managers.

In Berkeley Postgres each relation was tagged with the ID of the storage
manager to use for it.  This is gone.  It would be more reasonable to
associate storage managers with tablespaces (a feature not present as this
text is being written, but one likely to emerge soon).

The files in this directory, and their contents, are

    smgrtype.c	Storage manager type -- maps string names to storage manager
		IDs and provides simple comparison operators.  This is the
		regproc support for type 'smgr' in the system catalogs.
		(This is vestigial since no columns of type smgr exist
		in the catalogs anymore.)

    smgr.c	The storage manager switch dispatch code.  The routines in
		this file call the appropriate storage manager to do hardware
		accesses requested by the backend.  smgr.c also manages the
		file handle cache (SMgrRelation table).

    md.c	The magnetic disk storage manager.

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/storage/relfilenode.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.
@


1.5
log
@More README src cleanups.
@
text
@d1 1
a1 1
$PostgreSQL: pgsql/src/backend/storage/smgr/README,v 1.4 2008/03/20 17:55:15 momjian Exp $
d35 17
@


1.4
log
@Make source code READMEs more consistent.  Add CVS tags to all README files.
@
text
@d1 1
a1 1
# $PostgreSQL: pgsql/src/backend/storage/smgr/README,v 1.3 2004/02/10 01:55:26 tgl Exp $
d4 1
a4 1
---------------
@


1.3
log
@Restructure smgr API as per recent proposal.  smgr no longer depends on
the relcache, and so the notion of 'blind write' is gone.  This should
improve efficiency in bgwriter and background checkpoint processes.
Internal restructuring in md.c to remove the not-very-useful array of
MdfdVec objects --- might as well just use pointers.
Also remove the long-dead 'persistent main memory' storage manager (mm.c),
since it seems quite unlikely to ever get resurrected.
@
text
@d1 4
a4 1
# $PostgreSQL: pgsql-server/src/backend/storage/smgr/README,v 1.2 2003/11/29 19:51:57 pgsql Exp $
@


1.2
log
@
$Header: -> $PostgreSQL Changes ...
@
text
@d1 1
a1 1
# $PostgreSQL: /cvsroot/pgsql-server/src/backend/storage/smgr/README,v 1.1.1.1 1996/07/09 06:21:59 scrappy Exp $
d3 12
a14 10
This directory contains the code that supports the Postgres storage manager
switch and all of the installed storage managers.  In released systems,
the only supported storage manager is the magnetic disk manager.  At UC
Berkeley, the Sony WORM optical disk jukebox and persistent main memory are
also supported.

As of Postgres Release 3.0, every relation in the system is tagged with the
storage manager on which it resides.  The storage manager switch code turns
what used to by filesystem operations into operations on the correct store,
for any given relation.
d21 2
d26 2
a27 1
		accesses requested by the backend.
d31 1
a31 15
    mm.c	The persistent main memory storage manager (#undef'ed in
		tmp/c.h for all distributed systems).

    sj.c	The sony jukebox storage manager and cache management code
		(#undef'ed in tmp/c.h for all distributed systems).  The
		routines in this file allocate extents, maintain block
		maps, and guarantee the persistence and coherency of a cache
		of jukebox blocks on magnetic disk.

    pgjb.c	The postgres jukebox interface routines.  The routines here
		handle exclusion on the physical device and translate requests
		from the storage manager code (sj.c) into jbaccess calls.

    jbaccess.c	Access code for the physical Sony jukebox device.  This code
		was swiped from Andy McFadden's jblib.a code at UC Berkeley.
@


1.1
log
@Initial revision
@
text
@d1 1
a1 1
# $Header: /usr/local/cvsroot/postgres95/postgres95/src/backend/storage/smgr/README,v 1.1.1.1 1996/07/09 05:32:18 scrappy Exp $
@


1.1.1.1
log
@Postgres95 1.01 Distribution - Virgin Sources
@
text
@@
