mirror of
https://github.com/postgres/postgres.git
synced 2025-07-28 23:42:10 +03:00
Restructure LOCKTAG as per discussions of a couple months ago.
Essentially, we shoehorn in a lockable-object-type field by taking a byte away from the lockmethodid, which can surely fit in one byte instead of two. This allows less artificial definitions of all the other fields of LOCKTAG; we can get rid of the special pg_xactlock pseudo-relation, and also support locks on individual tuples and general database objects (including shared objects). None of those possibilities are actually exploited just yet, however. I removed pg_xactlock from pg_class, but did not force initdb for that change. At this point, relkind 's' (SPECIAL) is unused and could be removed entirely.
This commit is contained in:
@ -8,7 +8,7 @@
|
||||
*
|
||||
*
|
||||
* IDENTIFICATION
|
||||
* $PostgreSQL: pgsql/src/backend/access/heap/hio.c,v 1.54 2004/12/31 21:59:16 pgsql Exp $
|
||||
* $PostgreSQL: pgsql/src/backend/access/heap/hio.c,v 1.55 2005/04/29 22:28:23 tgl Exp $
|
||||
*
|
||||
*-------------------------------------------------------------------------
|
||||
*/
|
||||
@ -79,11 +79,6 @@ RelationPutHeapTuple(Relation relation,
|
||||
* happen if space is freed in that page after heap_update finds there's not
|
||||
* enough there). In that case, the page will be pinned and locked only once.
|
||||
*
|
||||
* Note that we use LockPage(rel, 0) to lock relation for extension.
|
||||
* We can do this as long as in all other places we use page-level locking
|
||||
* for indices only. Alternatively, we could define pseudo-table as
|
||||
* we do for transactions with XactLockTable.
|
||||
*
|
||||
* ereport(ERROR) is allowed here, so this routine *must* be called
|
||||
* before any (unlogged) changes are made in buffer pool.
|
||||
*/
|
||||
@ -235,7 +230,7 @@ RelationGetBufferForTuple(Relation relation, Size len,
|
||||
needLock = !RELATION_IS_LOCAL(relation);
|
||||
|
||||
if (needLock)
|
||||
LockPage(relation, 0, ExclusiveLock);
|
||||
LockRelationForExtension(relation, ExclusiveLock);
|
||||
|
||||
/*
|
||||
* XXX This does an lseek - rather expensive - but at the moment it is
|
||||
@ -251,7 +246,7 @@ RelationGetBufferForTuple(Relation relation, Size len,
|
||||
* extend the relation some more.
|
||||
*/
|
||||
if (needLock)
|
||||
UnlockPage(relation, 0, ExclusiveLock);
|
||||
UnlockRelationForExtension(relation, ExclusiveLock);
|
||||
|
||||
/*
|
||||
* We can be certain that locking the otherBuffer first is OK, since
|
||||
|
Reference in New Issue
Block a user