aboutsummaryrefslogtreecommitdiff
path: root/src/backend/storage/buffer/buf_table.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2000-05-19 03:22:31 +0000
committerTom Lane <tgl@sss.pgh.pa.us>2000-05-19 03:22:31 +0000
commitf923260ec8aa5c02b806fe0b5f3b6d8ce628c318 (patch)
treec6c1347af70caf922357235d56f5d8d122e5afff /src/backend/storage/buffer/buf_table.c
parentdb90fdf9abedf57c2fc8fd34da18ae647f67cfa9 (diff)
downloadpostgresql-f923260ec8aa5c02b806fe0b5f3b6d8ce628c318.tar.gz
postgresql-f923260ec8aa5c02b806fe0b5f3b6d8ce628c318.zip
Revise FlushRelationBuffers/ReleaseRelationBuffers per discussion with
Hiroshi. ReleaseRelationBuffers now removes rel's buffers from pool, instead of merely marking them nondirty. The old code would leave valid buffers for a deleted relation, which didn't cause any known problems but can't possibly be a good idea. There were several places which called ReleaseRelationBuffers *and* FlushRelationBuffers, which is now unnecessary; but there were others that did not. FlushRelationBuffers no longer emits a warning notice if it finds dirty buffers to flush, because with the current bufmgr behavior that's not an unexpected condition. Also, FlushRelationBuffers will flush out all dirty buffers for the relation regardless of block number. This ensures that pg_upgrade's expectations are met about tuple on-row status bits being up-to-date on disk. Lastly, tweak BufTableDelete() to clear the buffer's tag so that no one can mistake it for being a still-valid buffer for the page it once held. Formerly, the buffer would not be found by buffer hashtable searches after BufTableDelete(), but it would still be thought to belong to its old relation by the routines that sequentially scan the shared-buffer array. Again I know of no bugs caused by that, but it still can't be a good idea.
Diffstat (limited to 'src/backend/storage/buffer/buf_table.c')
-rw-r--r--src/backend/storage/buffer/buf_table.c11
1 files changed, 10 insertions, 1 deletions
diff --git a/src/backend/storage/buffer/buf_table.c b/src/backend/storage/buffer/buf_table.c
index 4c9b8e7cea9..8139337e352 100644
--- a/src/backend/storage/buffer/buf_table.c
+++ b/src/backend/storage/buffer/buf_table.c
@@ -8,7 +8,7 @@
*
*
* IDENTIFICATION
- * $Header: /cvsroot/pgsql/src/backend/storage/buffer/buf_table.c,v 1.16 2000/01/26 05:56:50 momjian Exp $
+ * $Header: /cvsroot/pgsql/src/backend/storage/buffer/buf_table.c,v 1.17 2000/05/19 03:22:28 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@@ -119,6 +119,15 @@ BufTableDelete(BufferDesc *buf)
return FALSE;
}
+ /*
+ * Clear the buffer's tag. This doesn't matter for the hash table,
+ * since the buffer is already removed from it, but it ensures that
+ * sequential searches through the buffer table won't think the
+ * buffer is still valid for its old page.
+ */
+ buf->tag.relId.relId = InvalidOid;
+ buf->tag.relId.dbId = InvalidOid;
+
return TRUE;
}