|
7 | 7 | * |
8 | 8 | * |
9 | 9 | * IDENTIFICATION |
10 | | - * $Id: hio.c,v 1.18 1999/05/01 15:04:46 vadim Exp $ |
| 10 | + * $Id: hio.c,v 1.19 1999/05/07 01:22:53 vadim Exp $ |
11 | 11 | * |
12 | 12 | *------------------------------------------------------------------------- |
13 | 13 | */ |
@@ -111,14 +111,13 @@ RelationPutHeapTupleAtEnd(Relation relation, HeapTuple tuple) |
111 | 111 | Itemitem; |
112 | 112 |
|
113 | 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 |
| 114 | + * Lock relation for extention. We can use LockPage here as long as |
| 115 | + * in all other places we use page-level locking for indices only. |
| 116 | + * Alternatevely, we could define pseudo-table as we do for |
| 117 | + * transactions with XactLockTable. |
119 | 118 | */ |
120 | 119 | if (!relation->rd_myxactonly) |
121 | | -LockPage(relation,0,ExtendLock); |
| 120 | +LockPage(relation,0,ExclusiveLock); |
122 | 121 |
|
123 | 122 | /* |
124 | 123 | * XXX This does an lseek - VERY expensive - but at the moment it is |
@@ -166,7 +165,7 @@ RelationPutHeapTupleAtEnd(Relation relation, HeapTuple tuple) |
166 | 165 | } |
167 | 166 |
|
168 | 167 | if (!relation->rd_myxactonly) |
169 | | -UnlockPage(relation,0,ExtendLock); |
| 168 | +UnlockPage(relation,0,ExclusiveLock); |
170 | 169 |
|
171 | 170 | offnum=PageAddItem((Page)pageHeader, (Item)tuple->t_data, |
172 | 171 | tuple->t_len,InvalidOffsetNumber,LP_USED); |
|