7
7
*
8
8
*
9
9
* IDENTIFICATION
10
- * $Header: /cvsroot/pgsql/src/backend/access/transam/varsup.c,v 1.15 1998/01/07 21:02:21 momjian Exp $
10
+ * $Header: /cvsroot/pgsql/src/backend/access/transam/varsup.c,v 1.16 1998/07/21 06:17:13 vadim Exp $
11
11
*
12
12
*-------------------------------------------------------------------------
13
13
*/
@@ -31,6 +31,8 @@ static void VariableRelationPutNextOid(Oid *oidP);
31
31
*/
32
32
int OidGenLockId ;
33
33
34
+ VariableCache ShmemVariableCache = NULL ;
35
+
34
36
/* ----------------------------------------------------------------
35
37
* variable relation query/update routines
36
38
* ----------------------------------------------------------------
@@ -258,16 +260,7 @@ VariableRelationPutNextOid(Oid *oidP)
258
260
* In the version 2 transaction system, transaction id's are
259
261
* restricted in several ways.
260
262
*
261
- * First, all transaction id's are even numbers (4, 88, 121342, etc).
262
- * This means the binary representation of the number will never
263
- * have the least significent bit set. This bit is reserved to
264
- * indicate that the transaction id does not in fact hold an XID,
265
- * but rather a commit time. This makes it possible for the
266
- * vaccuum daemon to disgard information from the log and time
267
- * relations for committed tuples. This is important when archiving
268
- * tuples to an optical disk because tuples with commit times
269
- * stored in their xid fields will not need to consult the log
270
- * and time relations.
263
+ * -- Old comments removed --
271
264
*
272
265
* Second, since we may someday preform compression of the data
273
266
* in the log and time relations, we cause the numbering of the
@@ -276,32 +269,16 @@ VariableRelationPutNextOid(Oid *oidP)
276
269
* transaction id's 0 - 510 will never be used. This space is
277
270
* in fact used to store the version number of the postgres
278
271
* transaction log and will someday store compression information
279
- * about the log.
280
- *
281
- * Lastly, rather then access the variable relation each time
282
- * a backend requests a new transction id, we "prefetch" 32
283
- * transaction id's by incrementing the nextXid stored in the
284
- * var relation by 64 (remember only even xid's are legal) and then
285
- * returning these id's one at a time until they are exhausted.
286
- * This means we reduce the number of accesses to the variable
287
- * relation by 32 for each backend.
288
- *
289
- * Note: 32 has no special significance. We don't want the
290
- * number to be too large because if when the backend
291
- * terminates, we lose the xid's we cached.
272
+ * about the log. -- this is also old comments...
292
273
*
293
274
* ----------------
294
275
*/
295
276
296
- #define VAR_XID_PREFETCH 32
297
-
298
- static int prefetched_xid_count = 0 ;
299
- static TransactionId next_prefetched_xid ;
277
+ #define VAR_XID_PREFETCH 1024
300
278
301
279
void
302
280
GetNewTransactionId (TransactionId * xid )
303
281
{
304
- TransactionId nextid ;
305
282
306
283
/* ----------------
307
284
* during bootstrap initialization, we return the special
@@ -314,51 +291,24 @@ GetNewTransactionId(TransactionId *xid)
314
291
return ;
315
292
}
316
293
317
- /* ----------------
318
- * if we run out of prefetched xids, then we get some
319
- * more before handing them out to the caller.
320
- * ----------------
321
- */
322
-
323
- if (prefetched_xid_count == 0 )
294
+ SpinAcquire (OidGenLockId ); /* not good for concurrency... */
295
+
296
+ if (ShmemVariableCache -> xid_count == 0 )
324
297
{
325
- /* ----------------
326
- * obtain exclusive access to the variable relation page
327
- *
328
- * get the "next" xid from the variable relation
329
- * and save it in the prefetched id.
330
- * ----------------
331
- */
332
- SpinAcquire (OidGenLockId );
298
+ TransactionId nextid ;
299
+
333
300
VariableRelationGetNextXid (& nextid );
334
- TransactionIdStore (nextid , & next_prefetched_xid );
335
-
336
- /* ----------------
337
- * now increment the variable relation's next xid
338
- * and reset the prefetched_xid_count. We multiply
339
- * the id by two because our xid's are always even.
340
- * ----------------
341
- */
342
- prefetched_xid_count = VAR_XID_PREFETCH ;
343
- TransactionIdAdd (& nextid , prefetched_xid_count );
301
+ TransactionIdStore (nextid , & (ShmemVariableCache -> nextXid ));
302
+ ShmemVariableCache -> xid_count = VAR_XID_PREFETCH ;
303
+ TransactionIdAdd (& nextid , VAR_XID_PREFETCH );
344
304
VariableRelationPutNextXid (nextid );
345
- SpinRelease (OidGenLockId );
346
305
}
347
306
348
- /* ----------------
349
- * return the next prefetched xid in the pointer passed by
350
- * the user and decrement the prefetch count. We add two
351
- * to id we return the next time this is called because our
352
- * transaction ids are always even.
353
- *
354
- * XXX Transaction Ids used to be even as the low order bit was
355
- * used to determine commit status. This is no long true so
356
- * we now use even and odd transaction ids. -mer 5/26/92
357
- * ----------------
358
- */
359
- TransactionIdStore (next_prefetched_xid , xid );
360
- TransactionIdAdd (& next_prefetched_xid , 1 );
361
- prefetched_xid_count -- ;
307
+ TransactionIdStore (ShmemVariableCache -> nextXid , xid );
308
+ TransactionIdAdd (& (ShmemVariableCache -> nextXid ), 1 );
309
+ (ShmemVariableCache -> xid_count )-- ;
310
+
311
+ SpinRelease (OidGenLockId );
362
312
}
363
313
364
314
/* ----------------------------------------------------------------
0 commit comments