mirror of
https://github.com/postgres/postgres.git
synced 2025-11-16 15:02:33 +03:00
Make source code READMEs more consistent. Add CVS tags to all README files.
This commit is contained in:
Bruce Momjian
@@ -1,6 +1,6 @@
|
||||
$PostgreSQL: pgsql/src/backend/storage/buffer/README,v 1.12 2007/05/30 20:11:58 tgl Exp $
|
||||
$PostgreSQL: pgsql/src/backend/storage/buffer/README,v 1.13 2008/03/20 17:55:15 momjian Exp $
|
||||
|
||||
Notes about shared buffer access rules
|
||||
Notes About Shared Buffer Access Rules
|
||||
--------------------------------------
|
||||
|
||||
There are two separate access control mechanisms for shared disk buffers:
|
||||
@@ -92,7 +92,7 @@ for VACUUM's use, since we don't allow multiple VACUUMs concurrently on a
|
||||
single relation anyway.
|
||||
|
||||
|
||||
Buffer manager's internal locking
|
||||
Buffer Manager's Internal Locking
|
||||
---------------------------------
|
||||
|
||||
Before PostgreSQL 8.1, all operations of the shared buffer manager itself
|
||||
@@ -152,7 +152,7 @@ we could use per-backend LWLocks instead (a buffer header would then contain
|
||||
a field to show which backend is doing its I/O).
|
||||
|
||||
|
||||
Normal buffer replacement strategy
|
||||
Normal Buffer Replacement Strategy
|
||||
----------------------------------
|
||||
|
||||
There is a "free list" of buffers that are prime candidates for replacement.
|
||||
@@ -201,7 +201,7 @@ have to give up and try another buffer. This however is not a concern
|
||||
of the basic select-a-victim-buffer algorithm.)
|
||||
|
||||
|
||||
Buffer ring replacement strategy
|
||||
Buffer Ring Replacement Strategy
|
||||
---------------------------------
|
||||
|
||||
When running a query that needs to access a large number of pages just once,
|
||||
@@ -236,7 +236,7 @@ buffer, resulting in excessive WAL flushing. Allowing VACUUM to update
|
||||
256KB between WAL flushes should be more efficient.
|
||||
|
||||
|
||||
Background writer's processing
|
||||
Background Writer's Processing
|
||||
------------------------------
|
||||
|
||||
The background writer is designed to write out pages that are likely to be
|
||||
|
||||
@@ -1,9 +1,10 @@
|
||||
$PostgreSQL: pgsql/src/backend/storage/ipc/README,v 1.4 2003/11/29 19:51:56 pgsql Exp $
|
||||
Mon Jul 18 11:09:22 PDT 1988 W.KLAS
|
||||
$PostgreSQL: pgsql/src/backend/storage/ipc/README,v 1.5 2008/03/20 17:55:15 momjian Exp $
|
||||
|
||||
Cache invalidation synchronization routines:
|
||||
Cache Invalidation Synchronization Routines
|
||||
===========================================
|
||||
|
||||
Mon Jul 18 11:09:22 PDT 1988 W.KLAS
|
||||
|
||||
The cache synchronization is done using a message queue. Every
|
||||
backend can register a message which then has to be read by
|
||||
all backends. A message read by all backends is removed from the
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
$PostgreSQL: pgsql/src/backend/storage/lmgr/README,v 1.22 2007/10/26 20:45:10 alvherre Exp $
|
||||
$PostgreSQL: pgsql/src/backend/storage/lmgr/README,v 1.23 2008/03/20 17:55:15 momjian Exp $
|
||||
|
||||
|
||||
LOCKING OVERVIEW
|
||||
Locking Overview
|
||||
----------------
|
||||
|
||||
Postgres uses three types of interprocess locks:
|
||||
|
||||
@@ -45,7 +45,8 @@ when the wait time might exceed a few seconds.
|
||||
The rest of this README file discusses the regular lock manager in detail.
|
||||
|
||||
|
||||
LOCK DATA STRUCTURES
|
||||
Lock Data Structures
|
||||
--------------------
|
||||
|
||||
Lock methods describe the overall locking behavior. Currently there are
|
||||
two lock methods: DEFAULT and USER.
|
||||
@@ -187,7 +188,8 @@ procLink -
|
||||
---------------------------------------------------------------------------
|
||||
|
||||
|
||||
LOCK MANAGER INTERNAL LOCKING
|
||||
Lock Manager Internal Locking
|
||||
-----------------------------
|
||||
|
||||
Before PostgreSQL 8.2, all of the shared-memory data structures used by
|
||||
the lock manager were protected by a single LWLock, the LockMgrLock;
|
||||
@@ -246,7 +248,8 @@ tradeoff: we could instead recalculate the partition number from the LOCKTAG
|
||||
when needed.
|
||||
|
||||
|
||||
THE DEADLOCK DETECTION ALGORITHM
|
||||
The Deadlock Detection Algorithm
|
||||
--------------------------------
|
||||
|
||||
Since we allow user transactions to request locks in any order, deadlock
|
||||
is possible. We use a deadlock detection/breaking algorithm that is
|
||||
@@ -445,7 +448,8 @@ eventually lead to the discovery of the additional constraint B before C.)
|
||||
|
||||
Got that?
|
||||
|
||||
Miscellaneous notes:
|
||||
Miscellaneous Notes
|
||||
-------------------
|
||||
|
||||
1. It is easily proven that no deadlock will be missed due to our
|
||||
asynchronous invocation of deadlock checking. A deadlock cycle in the WFG
|
||||
@@ -495,7 +499,8 @@ The caller can then send a cancellation signal. This implements the
|
||||
principle that autovacuum has a low locking priority (eg it must not block
|
||||
DDL on the table).
|
||||
|
||||
USER LOCKS
|
||||
User Locks
|
||||
----------
|
||||
|
||||
User locks are handled totally on the application side as long term
|
||||
cooperative locks which extend beyond the normal transaction boundaries.
|
||||
|
||||
@@ -1,4 +1,7 @@
|
||||
# $PostgreSQL: pgsql/src/backend/storage/smgr/README,v 1.3 2004/02/10 01:55:26 tgl Exp $
|
||||
# $PostgreSQL: pgsql/src/backend/storage/smgr/README,v 1.4 2008/03/20 17:55:15 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
|
||||
|
||||
Reference in New Issue
Block a user