Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitde09da5

Browse files
committed
Wups, managed to break ANALYZE with one aspect of that heap_fetch change.
1 parent3f4d488 commitde09da5

File tree

3 files changed

+31
-17
lines changed

3 files changed

+31
-17
lines changed

‎src/backend/access/heap/heapam.c‎

Lines changed: 24 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@
88
*
99
*
1010
* IDENTIFICATION
11-
* $Header: /cvsroot/pgsql/src/backend/access/heap/heapam.c,v 1.136 2002/05/2418:57:55 tgl Exp $
11+
* $Header: /cvsroot/pgsql/src/backend/access/heap/heapam.c,v 1.137 2002/05/2419:52:43 tgl Exp $
1212
*
1313
*
1414
* INTERFACE ROUTINES
@@ -873,15 +873,24 @@ heap_getnext(HeapScanDesc scan, ScanDirection direction)
873873
* the tuple, fill in the remaining fields of *tuple, and check the tuple
874874
* against the specified snapshot.
875875
*
876-
* If successful (tuple passes snapshot time qual), then *userbuf is set to
877-
* the buffer holding the tuple and TRUE is returned. The caller must
878-
* unpin the buffer when done with the tuple.
876+
* If successful (tuplefound andpasses snapshot time qual), then *userbuf
877+
*is set tothe buffer holding the tuple and TRUE is returned. The caller
878+
*mustunpin the buffer when done with the tuple.
879879
*
880-
* If the tuple fails the time qual check, then FALSE will be returned.
881-
* When the caller specifies keep_buf = true, we retain the pin on the
882-
* buffer and return it in *userbuf (so the caller can still access the
883-
* tuple); when keep_buf = false, the pin is released and *userbuf is set
880+
* If the tuple is not found, then tuple->t_data is set to NULL, *userbuf
881+
* is set to InvalidBuffer, and FALSE is returned.
882+
*
883+
* If the tuple is found but fails the time qual check, then FALSE will be
884+
* returned. When the caller specifies keep_buf = true, we retain the pin
885+
* on the buffer and return it in *userbuf (so the caller can still access
886+
* the tuple); when keep_buf = false, the pin is released and *userbuf is set
884887
* to InvalidBuffer.
888+
*
889+
* It is somewhat inconsistent that we elog() on invalid block number but
890+
* return false on invalid item number. This is historical. The only
891+
* justification I can see is that the caller can relatively easily check the
892+
* block number for validity, but cannot check the item number without reading
893+
* the page himself.
885894
*/
886895
bool
887896
heap_fetch(Relationrelation,
@@ -928,17 +937,18 @@ heap_fetch(Relation relation,
928937
lp=PageGetItemId(dp,offnum);
929938

930939
/*
931-
* more sanity checks
940+
* must check for deleted tuple (see for example analyze.c, which is
941+
* careful to pass an offnum in range, but doesn't know if the offnum
942+
* actually corresponds to an undeleted tuple).
932943
*/
933944
if (!ItemIdIsUsed(lp))
934945
{
935946
LockBuffer(buffer,BUFFER_LOCK_UNLOCK);
936947
ReleaseBuffer(buffer);
937-
938-
elog(ERROR,"heap_fetch: invalid tuple id (%s, %lu, %u)",
939-
RelationGetRelationName(relation),
940-
(unsigned long)ItemPointerGetBlockNumber(tid),
941-
offnum);
948+
*userbuf=InvalidBuffer;
949+
tuple->t_datamcxt=NULL;
950+
tuple->t_data=NULL;
951+
return false;
942952
}
943953

944954
/*

‎src/backend/access/index/indexam.c‎

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@
88
*
99
*
1010
* IDENTIFICATION
11-
* $Header: /cvsroot/pgsql/src/backend/access/index/indexam.c,v 1.59 2002/05/2418:57:55 tgl Exp $
11+
* $Header: /cvsroot/pgsql/src/backend/access/index/indexam.c,v 1.60 2002/05/2419:52:43 tgl Exp $
1212
*
1313
* INTERFACE ROUTINES
1414
*index_open- open an index relation by relation OID
@@ -444,6 +444,10 @@ index_getnext(IndexScanDesc scan, ScanDirection direction)
444444
&scan->xs_pgstat_info))
445445
break;
446446

447+
/* Skip if no tuple at this location */
448+
if (heapTuple->t_data==NULL)
449+
continue;/* should we raise an error instead? */
450+
447451
/*
448452
* If we can't see it, maybe no one else can either. Check to see
449453
* if the tuple is dead to all transactions. If so, signal the

‎src/backend/access/nbtree/nbtinsert.c‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@
88
*
99
*
1010
* IDENTIFICATION
11-
* $Header: /cvsroot/pgsql/src/backend/access/nbtree/nbtinsert.c,v 1.91 2002/05/2418:57:55 tgl Exp $
11+
* $Header: /cvsroot/pgsql/src/backend/access/nbtree/nbtinsert.c,v 1.92 2002/05/2419:52:43 tgl Exp $
1212
*
1313
*-------------------------------------------------------------------------
1414
*/
@@ -248,7 +248,7 @@ _bt_check_unique(Relation rel, BTItem btitem, Relation heapRel,
248248
elog(ERROR,"Cannot insert a duplicate key into unique index %s",
249249
RelationGetRelationName(rel));
250250
}
251-
else
251+
elseif (htup.t_data!=NULL)
252252
{
253253
/*
254254
* Hmm, if we can't see the tuple, maybe it can be

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp