diff options
Diffstat (limited to 'src/backend/storage/buffer/README')
| -rw-r--r-- | src/backend/storage/buffer/README | 27 |
1 files changed, 13 insertions, 14 deletions
diff --git a/src/backend/storage/buffer/README b/src/backend/storage/buffer/README index 41c98515324..9b8c6a745e8 100644 --- a/src/backend/storage/buffer/README +++ b/src/backend/storage/buffer/README @@ -1,4 +1,4 @@ -$PostgreSQL: pgsql/src/backend/storage/buffer/README,v 1.8 2005/03/04 20:21:06 tgl Exp $ +$PostgreSQL: pgsql/src/backend/storage/buffer/README,v 1.9 2006/03/31 23:32:06 tgl Exp $ Notes about shared buffer access rules -------------------------------------- @@ -12,19 +12,18 @@ the relation. Relation-level locks are not discussed here.) Pins: one must "hold a pin on" a buffer (increment its reference count) before being allowed to do anything at all with it. An unpinned buffer is subject to being reclaimed and reused for a different page at any instant, -so touching it is unsafe. Typically a pin is acquired via ReadBuffer and -released via WriteBuffer (if one modified the page) or ReleaseBuffer (if not). -It is OK and indeed common for a single backend to pin a page more than -once concurrently; the buffer manager handles this efficiently. It is -considered OK to hold a pin for long intervals --- for example, sequential -scans hold a pin on the current page until done processing all the tuples -on the page, which could be quite a while if the scan is the outer scan of -a join. Similarly, btree index scans hold a pin on the current index page. -This is OK because normal operations never wait for a page's pin count to -drop to zero. (Anything that might need to do such a wait is instead -handled by waiting to obtain the relation-level lock, which is why you'd -better hold one first.) Pins may not be held across transaction -boundaries, however. +so touching it is unsafe. Normally a pin is acquired via ReadBuffer and +released via ReleaseBuffer. It is OK and indeed common for a single +backend to pin a page more than once concurrently; the buffer manager +handles this efficiently. It is considered OK to hold a pin for long +intervals --- for example, sequential scans hold a pin on the current page +until done processing all the tuples on the page, which could be quite a +while if the scan is the outer scan of a join. Similarly, btree index +scans hold a pin on the current index page. This is OK because normal +operations never wait for a page's pin count to drop to zero. (Anything +that might need to do such a wait is instead handled by waiting to obtain +the relation-level lock, which is why you'd better hold one first.) Pins +may not be held across transaction boundaries, however. Buffer content locks: there are two kinds of buffer lock, shared and exclusive, which act just as you'd expect: multiple backends can hold shared locks on |