1996-07-09 08:22:35 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* hio.c
|
1997-09-07 07:04:48 +02:00
|
|
|
* POSTGRES heap access method input/output code.
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2002-06-20 22:29:54 +02:00
|
|
|
* Portions Copyright (c) 1996-2002, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2002-06-20 22:29:54 +02:00
|
|
|
* $Id: hio.c,v 1.45 2002/06/20 20:29:25 momjian Exp $
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
1999-07-16 01:04:24 +02:00
|
|
|
#include "postgres.h"
|
1996-10-20 10:32:11 +02:00
|
|
|
|
1999-07-16 01:04:24 +02:00
|
|
|
#include "access/heapam.h"
|
1999-07-16 07:00:38 +02:00
|
|
|
#include "access/hio.h"
|
2001-06-29 23:08:25 +02:00
|
|
|
#include "storage/freespace.h"
|
|
|
|
|
1996-10-21 07:59:49 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*
|
2001-03-22 05:01:46 +01:00
|
|
|
* RelationPutHeapTuple - place tuple at specified page
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2000-07-03 04:54:21 +02:00
|
|
|
* !!! ELOG(ERROR) IS DISALLOWED HERE !!!
|
1998-12-15 13:47:01 +01:00
|
|
|
*
|
2001-07-14 00:52:58 +02:00
|
|
|
* Note - caller must hold BUFFER_LOCK_EXCLUSIVE on the buffer.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
|
|
|
void
|
|
|
|
RelationPutHeapTuple(Relation relation,
|
1998-12-15 13:47:01 +01:00
|
|
|
Buffer buffer,
|
1997-09-07 07:04:48 +02:00
|
|
|
HeapTuple tuple)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1999-05-25 18:15:34 +02:00
|
|
|
Page pageHeader;
|
|
|
|
OffsetNumber offnum;
|
|
|
|
ItemId itemId;
|
|
|
|
Item item;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2001-03-22 07:16:21 +01:00
|
|
|
/*
|
|
|
|
* increment access statistics
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
|
|
|
IncrHeapAccessStat(local_RelationPutHeapTuple);
|
|
|
|
IncrHeapAccessStat(global_RelationPutHeapTuple);
|
|
|
|
|
2001-07-14 00:52:58 +02:00
|
|
|
/* Add the tuple to the page */
|
|
|
|
pageHeader = BufferGetPage(buffer);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2001-07-14 00:52:58 +02:00
|
|
|
offnum = PageAddItem(pageHeader, (Item) tuple->t_data,
|
1997-09-07 07:04:48 +02:00
|
|
|
tuple->t_len, InvalidOffsetNumber, LP_USED);
|
|
|
|
|
2000-07-03 04:54:21 +02:00
|
|
|
if (offnum == InvalidOffsetNumber)
|
Commit to match discussed elog() changes. Only update is that LOG is
now just below FATAL in server_min_messages. Added more text to
highlight ordering difference between it and client_min_messages.
---------------------------------------------------------------------------
REALLYFATAL => PANIC
STOP => PANIC
New INFO level the prints to client by default
New LOG level the prints to server log by default
Cause VACUUM information to print only to the client
NOTICE => INFO where purely information messages are sent
DEBUG => LOG for purely server status messages
DEBUG removed, kept as backward compatible
DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1 added
DebugLvl removed in favor of new DEBUG[1-5] symbols
New server_min_messages GUC parameter with values:
DEBUG[5-1], INFO, NOTICE, ERROR, LOG, FATAL, PANIC
New client_min_messages GUC parameter with values:
DEBUG[5-1], LOG, INFO, NOTICE, ERROR, FATAL, PANIC
Server startup now logged with LOG instead of DEBUG
Remove debug_level GUC parameter
elog() numbers now start at 10
Add test to print error message if older elog() values are passed to elog()
Bootstrap mode now has a -d that requires an argument, like postmaster
2002-03-02 22:39:36 +01:00
|
|
|
elog(PANIC, "RelationPutHeapTuple: failed to add tuple");
|
2000-07-03 04:54:21 +02:00
|
|
|
|
2001-07-14 00:52:58 +02:00
|
|
|
/* Update tuple->t_self to the actual position where it was stored */
|
|
|
|
ItemPointerSet(&(tuple->t_self), BufferGetBlockNumber(buffer), offnum);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2001-07-14 00:52:58 +02:00
|
|
|
/* Insert the correct position into CTID of the stored tuple, too */
|
|
|
|
itemId = PageGetItemId(pageHeader, offnum);
|
|
|
|
item = PageGetItem(pageHeader, itemId);
|
|
|
|
((HeapTupleHeader) item)->t_ctid = tuple->t_self;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2000-07-03 04:54:21 +02:00
|
|
|
* RelationGetBufferForTuple
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2001-06-29 23:08:25 +02:00
|
|
|
* Returns pinned and exclusive-locked buffer of a page in given relation
|
|
|
|
* with free space >= given len.
|
|
|
|
*
|
|
|
|
* If otherBuffer is not InvalidBuffer, then it references a previously
|
|
|
|
* pinned buffer of another page in the same relation; on return, this
|
|
|
|
* buffer will also be exclusive-locked. (This case is used by heap_update;
|
|
|
|
* the otherBuffer contains the tuple being updated.)
|
2000-09-07 11:58:38 +02:00
|
|
|
*
|
2001-06-29 23:08:25 +02:00
|
|
|
* The reason for passing otherBuffer is that if two backends are doing
|
|
|
|
* concurrent heap_update operations, a deadlock could occur if they try
|
|
|
|
* to lock the same two buffers in opposite orders. To ensure that this
|
|
|
|
* can't happen, we impose the rule that buffers of a relation must be
|
|
|
|
* locked in increasing page number order. This is most conveniently done
|
|
|
|
* by having RelationGetBufferForTuple lock them both, with suitable care
|
|
|
|
* for ordering.
|
1997-09-07 07:04:48 +02:00
|
|
|
*
|
2001-06-29 23:08:25 +02:00
|
|
|
* NOTE: it is unlikely, but not quite impossible, for otherBuffer to be the
|
|
|
|
* same buffer we select for insertion of the new tuple (this could only
|
|
|
|
* happen if space is freed in that page after heap_update finds there's not
|
2001-10-25 07:50:21 +02:00
|
|
|
* enough there). In that case, the page will be pinned and locked only once.
|
2001-06-29 23:08:25 +02:00
|
|
|
*
|
|
|
|
* 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
|
2001-05-17 00:35:12 +02:00
|
|
|
* for indices only. Alternatively, we could define pseudo-table as
|
|
|
|
* we do for transactions with XactLockTable.
|
|
|
|
*
|
|
|
|
* ELOG(ERROR) is allowed here, so this routine *must* be called
|
|
|
|
* before any (unlogged) changes are made in buffer pool.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-03 04:54:21 +02:00
|
|
|
Buffer
|
2001-05-17 00:35:12 +02:00
|
|
|
RelationGetBufferForTuple(Relation relation, Size len,
|
2001-06-29 23:08:25 +02:00
|
|
|
Buffer otherBuffer)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2001-05-12 21:58:28 +02:00
|
|
|
Buffer buffer = InvalidBuffer;
|
1997-09-08 04:41:22 +02:00
|
|
|
Page pageHeader;
|
2001-06-29 23:08:25 +02:00
|
|
|
Size pageFreeSpace;
|
|
|
|
BlockNumber targetBlock,
|
|
|
|
otherBlock;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-03 04:54:21 +02:00
|
|
|
len = MAXALIGN(len); /* be conservative */
|
1999-11-29 05:34:55 +01:00
|
|
|
|
|
|
|
/*
|
2000-07-03 04:54:21 +02:00
|
|
|
* If we're gonna fail for oversize tuple, do it right away
|
1999-11-29 05:34:55 +01:00
|
|
|
*/
|
|
|
|
if (len > MaxTupleSize)
|
2000-11-16 06:51:07 +01:00
|
|
|
elog(ERROR, "Tuple is too big: size %lu, max size %ld",
|
2001-03-22 05:01:46 +01:00
|
|
|
(unsigned long) len, MaxTupleSize);
|
1999-11-29 05:34:55 +01:00
|
|
|
|
2001-06-29 23:08:25 +02:00
|
|
|
if (otherBuffer != InvalidBuffer)
|
|
|
|
otherBlock = BufferGetBlockNumber(otherBuffer);
|
|
|
|
else
|
2001-10-25 07:50:21 +02:00
|
|
|
otherBlock = InvalidBlockNumber; /* just to keep compiler
|
|
|
|
* quiet */
|
2001-06-29 23:08:25 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/*
|
2001-06-29 23:08:25 +02:00
|
|
|
* 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,
|
2001-10-25 07:50:21 +02:00
|
|
|
* we ask the shared Free Space Map to locate a suitable page. Since
|
2001-06-29 23:08:25 +02:00
|
|
|
* 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
|
2001-10-25 07:50:21 +02:00
|
|
|
* 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.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2001-06-29 23:08:25 +02:00
|
|
|
|
|
|
|
targetBlock = relation->rd_targblock;
|
|
|
|
|
|
|
|
if (targetBlock == InvalidBlockNumber)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* We have no cached target page, so ask the FSM for an initial
|
|
|
|
* target.
|
|
|
|
*/
|
|
|
|
targetBlock = GetPageWithFreeSpace(&relation->rd_node, len);
|
2001-10-25 07:50:21 +02:00
|
|
|
|
2001-06-29 23:08:25 +02:00
|
|
|
/*
|
|
|
|
* 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)
|
|
|
|
{
|
2001-10-25 07:50:21 +02:00
|
|
|
BlockNumber nblocks = RelationGetNumberOfBlocks(relation);
|
2001-06-29 23:08:25 +02:00
|
|
|
|
|
|
|
if (nblocks > 0)
|
|
|
|
targetBlock = nblocks - 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
while (targetBlock != InvalidBlockNumber)
|
2000-09-07 11:58:38 +02:00
|
|
|
{
|
2001-06-29 23:08:25 +02:00
|
|
|
/*
|
2001-10-25 07:50:21 +02:00
|
|
|
* 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.
|
2001-06-29 23:08:25 +02:00
|
|
|
*/
|
|
|
|
if (otherBuffer == InvalidBuffer)
|
|
|
|
{
|
|
|
|
/* easy case */
|
|
|
|
buffer = ReadBuffer(relation, targetBlock);
|
|
|
|
LockBuffer(buffer, BUFFER_LOCK_EXCLUSIVE);
|
|
|
|
}
|
|
|
|
else if (otherBlock == targetBlock)
|
|
|
|
{
|
|
|
|
/* also easy case */
|
|
|
|
buffer = otherBuffer;
|
|
|
|
LockBuffer(buffer, BUFFER_LOCK_EXCLUSIVE);
|
|
|
|
}
|
|
|
|
else if (otherBlock < targetBlock)
|
2001-05-17 00:35:12 +02:00
|
|
|
{
|
2001-06-29 23:08:25 +02:00
|
|
|
/* lock other buffer first */
|
|
|
|
buffer = ReadBuffer(relation, targetBlock);
|
|
|
|
LockBuffer(otherBuffer, BUFFER_LOCK_EXCLUSIVE);
|
2001-05-17 00:35:12 +02:00
|
|
|
LockBuffer(buffer, BUFFER_LOCK_EXCLUSIVE);
|
|
|
|
}
|
2001-06-29 23:08:25 +02:00
|
|
|
else
|
|
|
|
{
|
|
|
|
/* lock target buffer first */
|
|
|
|
buffer = ReadBuffer(relation, targetBlock);
|
|
|
|
LockBuffer(buffer, BUFFER_LOCK_EXCLUSIVE);
|
|
|
|
LockBuffer(otherBuffer, BUFFER_LOCK_EXCLUSIVE);
|
|
|
|
}
|
2001-10-25 07:50:21 +02:00
|
|
|
|
2001-06-29 23:08:25 +02:00
|
|
|
/*
|
2001-10-25 07:50:21 +02:00
|
|
|
* Now we can check to see if there's enough free space here. If
|
|
|
|
* so, we're done.
|
2001-06-29 23:08:25 +02:00
|
|
|
*/
|
|
|
|
pageHeader = (Page) BufferGetPage(buffer);
|
|
|
|
pageFreeSpace = PageGetFreeSpace(pageHeader);
|
|
|
|
if (len <= pageFreeSpace)
|
|
|
|
{
|
|
|
|
/* use this page as future insert target, too */
|
|
|
|
relation->rd_targblock = targetBlock;
|
|
|
|
return buffer;
|
|
|
|
}
|
2001-10-25 07:50:21 +02:00
|
|
|
|
2001-06-29 23:08:25 +02:00
|
|
|
/*
|
2001-10-25 07:50:21 +02:00
|
|
|
* 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.
|
2001-06-29 23:08:25 +02:00
|
|
|
*/
|
|
|
|
LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
|
|
|
|
if (otherBuffer == InvalidBuffer)
|
|
|
|
ReleaseBuffer(buffer);
|
|
|
|
else if (otherBlock != targetBlock)
|
|
|
|
{
|
|
|
|
LockBuffer(otherBuffer, BUFFER_LOCK_UNLOCK);
|
|
|
|
ReleaseBuffer(buffer);
|
|
|
|
}
|
2001-10-25 07:50:21 +02:00
|
|
|
|
2001-06-29 23:08:25 +02:00
|
|
|
/*
|
|
|
|
* Update FSM as to condition of this page, and ask for another
|
|
|
|
* page to try.
|
|
|
|
*/
|
|
|
|
targetBlock = RecordAndGetPageWithFreeSpace(&relation->rd_node,
|
|
|
|
targetBlock,
|
|
|
|
pageFreeSpace,
|
|
|
|
len);
|
2000-09-07 11:58:38 +02:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
/*
|
2001-06-29 23:08:25 +02:00
|
|
|
* Have to extend the relation.
|
2001-05-12 21:58:28 +02:00
|
|
|
*
|
2001-10-25 07:50:21 +02:00
|
|
|
* 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.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2001-05-12 21:58:28 +02:00
|
|
|
if (!relation->rd_myxactonly)
|
|
|
|
LockPage(relation, 0, 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
|
2001-10-25 07:50:21 +02:00
|
|
|
* memory someplace, rather than relying on the kernel to do it for
|
|
|
|
* us?
|
2001-05-12 21:58:28 +02:00
|
|
|
*/
|
2001-06-29 23:08:25 +02:00
|
|
|
buffer = ReadBuffer(relation, P_NEW);
|
2001-05-12 21:58:28 +02:00
|
|
|
|
2001-06-29 23:08:25 +02:00
|
|
|
/*
|
2001-10-25 07:50:21 +02:00
|
|
|
* Release the file-extension lock; it's now OK for someone else to
|
|
|
|
* extend the relation some more.
|
2001-06-29 23:08:25 +02:00
|
|
|
*/
|
|
|
|
if (!relation->rd_myxactonly)
|
|
|
|
UnlockPage(relation, 0, ExclusiveLock);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2001-05-12 21:58:28 +02:00
|
|
|
/*
|
2001-10-25 07:50:21 +02:00
|
|
|
* We can be certain that locking the otherBuffer first is OK, since
|
|
|
|
* it must have a lower page number.
|
2001-05-12 21:58:28 +02:00
|
|
|
*/
|
2001-06-29 23:08:25 +02:00
|
|
|
if (otherBuffer != InvalidBuffer)
|
|
|
|
LockBuffer(otherBuffer, BUFFER_LOCK_EXCLUSIVE);
|
2001-05-12 21:58:28 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We need to initialize the empty new page.
|
|
|
|
*/
|
|
|
|
LockBuffer(buffer, BUFFER_LOCK_EXCLUSIVE);
|
|
|
|
pageHeader = (Page) BufferGetPage(buffer);
|
|
|
|
Assert(PageIsNew((PageHeader) pageHeader));
|
|
|
|
PageInit(pageHeader, BufferGetPageSize(buffer), 0);
|
|
|
|
|
|
|
|
if (len > PageGetFreeSpace(pageHeader))
|
|
|
|
{
|
|
|
|
/* We should not get here given the test at the top */
|
Commit to match discussed elog() changes. Only update is that LOG is
now just below FATAL in server_min_messages. Added more text to
highlight ordering difference between it and client_min_messages.
---------------------------------------------------------------------------
REALLYFATAL => PANIC
STOP => PANIC
New INFO level the prints to client by default
New LOG level the prints to server log by default
Cause VACUUM information to print only to the client
NOTICE => INFO where purely information messages are sent
DEBUG => LOG for purely server status messages
DEBUG removed, kept as backward compatible
DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1 added
DebugLvl removed in favor of new DEBUG[1-5] symbols
New server_min_messages GUC parameter with values:
DEBUG[5-1], INFO, NOTICE, ERROR, LOG, FATAL, PANIC
New client_min_messages GUC parameter with values:
DEBUG[5-1], LOG, INFO, NOTICE, ERROR, FATAL, PANIC
Server startup now logged with LOG instead of DEBUG
Remove debug_level GUC parameter
elog() numbers now start at 10
Add test to print error message if older elog() values are passed to elog()
Bootstrap mode now has a -d that requires an argument, like postmaster
2002-03-02 22:39:36 +01:00
|
|
|
elog(PANIC, "Tuple is too big: size %lu", (unsigned long) len);
|
2001-05-12 21:58:28 +02:00
|
|
|
}
|
1998-12-15 13:47:01 +01:00
|
|
|
|
2001-06-29 23:08:25 +02:00
|
|
|
/*
|
|
|
|
* 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
|
2001-10-25 07:50:21 +02:00
|
|
|
* (until VACUUM sees it)? Seems to depend on whether you expect the
|
2001-06-29 23:08:25 +02:00
|
|
|
* 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);
|
|
|
|
|
2001-05-12 21:58:28 +02:00
|
|
|
return buffer;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|