diff options
Diffstat (limited to 'src/backend/access/heap/hio.c')
| -rw-r--r-- | src/backend/access/heap/hio.c | 91 |
1 files changed, 44 insertions, 47 deletions
diff --git a/src/backend/access/heap/hio.c b/src/backend/access/heap/hio.c index fc1b0afd21e..800ee4a805b 100644 --- a/src/backend/access/heap/hio.c +++ b/src/backend/access/heap/hio.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/access/heap/hio.c,v 1.57 2005/06/20 18:37:01 tgl Exp $ + * $PostgreSQL: pgsql/src/backend/access/heap/hio.c,v 1.58 2005/10/15 02:49:08 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -80,7 +80,7 @@ RelationPutHeapTuple(Relation relation, * enough there). In that case, the page will be pinned and locked only once. * * If use_fsm is true (the normal case), we use FSM to help us find free - * space. If use_fsm is false, we always append a new empty page to the + * space. If use_fsm is false, we always append a new empty page to the * end of the relation if the tuple won't fit on the current target page. * This can save some cycles when we know the relation is new and doesn't * contain useful amounts of free space. @@ -122,22 +122,20 @@ RelationGetBufferForTuple(Relation relation, Size len, if (otherBuffer != InvalidBuffer) otherBlock = BufferGetBlockNumber(otherBuffer); else - otherBlock = InvalidBlockNumber; /* just to keep compiler - * quiet */ + otherBlock = InvalidBlockNumber; /* just to keep compiler quiet */ /* - * We first try to put the tuple on the same page we last inserted a - * tuple on, as cached in the relcache entry. If that doesn't work, - * we ask the shared Free Space Map to locate a suitable page. Since - * the FSM's info might be out of date, we have to be prepared to loop - * around and retry multiple times. (To insure this isn't an infinite - * loop, we must update the FSM with the correct amount of free space - * on each page that proves not to be suitable.) If the FSM has no - * record of a page with enough free space, we give up and extend the - * relation. + * We first try to put the tuple on the same page we last inserted a tuple + * on, as cached in the relcache entry. If that doesn't work, we ask the + * shared Free Space Map to locate a suitable page. Since the FSM's info + * might be out of date, we have to be prepared to loop around and retry + * multiple times. (To insure this isn't an infinite loop, we must update + * the FSM with the correct amount of free space on each page that proves + * not to be suitable.) If the FSM has no record of a page with enough + * free space, we give up and extend the relation. * - * When use_fsm is false, we either put the tuple onto the existing - * target page or extend the relation. + * When use_fsm is false, we either put the tuple onto the existing target + * page or extend the relation. */ targetBlock = relation->rd_targblock; @@ -151,9 +149,9 @@ RelationGetBufferForTuple(Relation relation, Size len, targetBlock = GetPageWithFreeSpace(&relation->rd_node, len); /* - * If the FSM knows nothing of the rel, try the last page before - * we give up and extend. This avoids one-tuple-per-page syndrome - * during bootstrapping or in a recently-started system. + * If the FSM knows nothing of the rel, try the last page before we + * give up and extend. This avoids one-tuple-per-page syndrome during + * bootstrapping or in a recently-started system. */ if (targetBlock == InvalidBlockNumber) { @@ -168,8 +166,8 @@ RelationGetBufferForTuple(Relation relation, Size len, { /* * Read and exclusive-lock the target block, as well as the other - * block if one was given, taking suitable care with lock ordering - * and the possibility they are the same block. + * block if one was given, taking suitable care with lock ordering and + * the possibility they are the same block. */ if (otherBuffer == InvalidBuffer) { @@ -199,8 +197,8 @@ RelationGetBufferForTuple(Relation relation, Size len, } /* - * Now we can check to see if there's enough free space here. If - * so, we're done. + * Now we can check to see if there's enough free space here. If so, + * we're done. */ pageHeader = (Page) BufferGetPage(buffer); pageFreeSpace = PageGetFreeSpace(pageHeader); @@ -213,9 +211,9 @@ RelationGetBufferForTuple(Relation relation, Size len, /* * Not enough space, so we must give up our page locks and pin (if - * any) and prepare to look elsewhere. We don't care which order - * we unlock the two buffers in, so this can be slightly simpler - * than the code above. + * any) and prepare to look elsewhere. We don't care which order we + * unlock the two buffers in, so this can be slightly simpler than the + * code above. */ LockBuffer(buffer, BUFFER_LOCK_UNLOCK); if (otherBuffer == InvalidBuffer) @@ -231,8 +229,8 @@ RelationGetBufferForTuple(Relation relation, Size len, break; /* - * Update FSM as to condition of this page, and ask for another - * page to try. + * Update FSM as to condition of this page, and ask for another page + * to try. */ targetBlock = RecordAndGetPageWithFreeSpace(&relation->rd_node, targetBlock, @@ -243,10 +241,10 @@ RelationGetBufferForTuple(Relation relation, Size len, /* * Have to extend the relation. * - * We have to use a lock to ensure no one else is extending the rel at - * the same time, else we will both try to initialize the same new - * page. We can skip locking for new or temp relations, however, - * since no one else could be accessing them. + * We have to use a lock to ensure no one else is extending the rel at the + * same time, else we will both try to initialize the same new page. We + * can skip locking for new or temp relations, however, since no one else + * could be accessing them. */ needLock = !RELATION_IS_LOCAL(relation); @@ -254,17 +252,16 @@ RelationGetBufferForTuple(Relation relation, Size len, LockRelationForExtension(relation, ExclusiveLock); /* - * XXX This does an lseek - rather expensive - but at the moment it is - * the only way to accurately determine how many blocks are in a - * relation. Is it worth keeping an accurate file length in shared - * memory someplace, rather than relying on the kernel to do it for - * us? + * XXX This does an lseek - rather expensive - but at the moment it is the + * only way to accurately determine how many blocks are in a relation. Is + * it worth keeping an accurate file length in shared memory someplace, + * rather than relying on the kernel to do it for us? */ buffer = ReadBuffer(relation, P_NEW); /* - * We can be certain that locking the otherBuffer first is OK, since - * it must have a lower page number. + * We can be certain that locking the otherBuffer first is OK, since it + * must have a lower page number. */ if (otherBuffer != InvalidBuffer) LockBuffer(otherBuffer, BUFFER_LOCK_EXCLUSIVE); @@ -275,10 +272,10 @@ RelationGetBufferForTuple(Relation relation, Size len, LockBuffer(buffer, BUFFER_LOCK_EXCLUSIVE); /* - * Release the file-extension lock; it's now OK for someone else to - * extend the relation some more. Note that we cannot release this - * lock before we have buffer lock on the new page, or we risk a - * race condition against vacuumlazy.c --- see comments therein. + * Release the file-extension lock; it's now OK for someone else to extend + * the relation some more. Note that we cannot release this lock before + * we have buffer lock on the new page, or we risk a race condition + * against vacuumlazy.c --- see comments therein. */ if (needLock) UnlockRelationForExtension(relation, ExclusiveLock); @@ -299,11 +296,11 @@ RelationGetBufferForTuple(Relation relation, Size len, /* * Remember the new page as our target for future insertions. * - * XXX should we enter the new page into the free space map immediately, - * or just keep it for this backend's exclusive use in the short run - * (until VACUUM sees it)? Seems to depend on whether you expect the - * current backend to make more insertions or not, which is probably a - * good bet most of the time. So for now, don't add it to FSM yet. + * XXX should we enter the new page into the free space map immediately, or + * just keep it for this backend's exclusive use in the short run (until + * VACUUM sees it)? Seems to depend on whether you expect the current + * backend to make more insertions or not, which is probably a good bet + * most of the time. So for now, don't add it to FSM yet. */ relation->rd_targblock = BufferGetBlockNumber(buffer); |