|
7 | 7 | * |
8 | 8 | * |
9 | 9 | * IDENTIFICATION |
10 | | - * $Id: hio.c,v 1.17 1999/02/13 23:14:24 momjian Exp $ |
| 10 | + * $Id: hio.c,v 1.18 1999/05/01 15:04:46 vadim Exp $ |
11 | 11 | * |
12 | 12 | *------------------------------------------------------------------------- |
13 | 13 | */ |
@@ -110,8 +110,15 @@ RelationPutHeapTupleAtEnd(Relation relation, HeapTuple tuple) |
110 | 110 | ItemIditemId; |
111 | 111 | Itemitem; |
112 | 112 |
|
| 113 | +/* |
| 114 | + * Actually, we lock _relation_ here, not page, but I believe |
| 115 | + * that locking page is faster... Obviously, we could get rid |
| 116 | + * of ExtendLock mode at all and use ExclusiveLock mode on |
| 117 | + * page 0, as long as we use page-level locking for indices only, |
| 118 | + * but we are in 6.5-beta currently...- vadim 05/01/99 |
| 119 | + */ |
113 | 120 | if (!relation->rd_myxactonly) |
114 | | -LockRelation(relation,ExtendLock); |
| 121 | +LockPage(relation,0,ExtendLock); |
115 | 122 |
|
116 | 123 | /* |
117 | 124 | * XXX This does an lseek - VERY expensive - but at the moment it is |
@@ -159,7 +166,7 @@ RelationPutHeapTupleAtEnd(Relation relation, HeapTuple tuple) |
159 | 166 | } |
160 | 167 |
|
161 | 168 | if (!relation->rd_myxactonly) |
162 | | -UnlockRelation(relation,ExtendLock); |
| 169 | +UnlockPage(relation,0,ExtendLock); |
163 | 170 |
|
164 | 171 | offnum=PageAddItem((Page)pageHeader, (Item)tuple->t_data, |
165 | 172 | tuple->t_len,InvalidOffsetNumber,LP_USED); |
|