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

Commit5afe171

Browse files
committed
VariableCache (next XID generator) is placed in shmem.
1 parent224a62c commit5afe171

File tree

3 files changed

+50
-73
lines changed

3 files changed

+50
-73
lines changed

‎src/backend/access/transam/varsup.c

Lines changed: 19 additions & 69 deletions
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@
77
*
88
*
99
* 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 $
1111
*
1212
*-------------------------------------------------------------------------
1313
*/
@@ -31,6 +31,8 @@ static void VariableRelationPutNextOid(Oid *oidP);
3131
*/
3232
intOidGenLockId;
3333

34+
VariableCacheShmemVariableCache=NULL;
35+
3436
/* ----------------------------------------------------------------
3537
* variable relation query/update routines
3638
* ----------------------------------------------------------------
@@ -258,16 +260,7 @@ VariableRelationPutNextOid(Oid *oidP)
258260
*In the version 2 transaction system, transaction id's are
259261
*restricted in several ways.
260262
*
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 --
271264
*
272265
*Second, since we may someday preform compression of the data
273266
*in the log and time relations, we cause the numbering of the
@@ -276,32 +269,16 @@ VariableRelationPutNextOid(Oid *oidP)
276269
*transaction id's 0 - 510 will never be used. This space is
277270
*in fact used to store the version number of the postgres
278271
*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...
292273
*
293274
* ----------------
294275
*/
295276

296-
#defineVAR_XID_PREFETCH32
297-
298-
staticintprefetched_xid_count=0;
299-
staticTransactionIdnext_prefetched_xid;
277+
#defineVAR_XID_PREFETCH1024
300278

301279
void
302280
GetNewTransactionId(TransactionId*xid)
303281
{
304-
TransactionIdnextid;
305282

306283
/* ----------------
307284
*during bootstrap initialization, we return the special
@@ -314,51 +291,24 @@ GetNewTransactionId(TransactionId *xid)
314291
return;
315292
}
316293

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)
324297
{
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+
TransactionIdnextid;
299+
333300
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);
344304
VariableRelationPutNextXid(nextid);
345-
SpinRelease(OidGenLockId);
346305
}
347306

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);
362312
}
363313

364314
/* ----------------------------------------------------------------

‎src/backend/storage/ipc/shmem.c

Lines changed: 12 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@
77
*
88
*
99
* IDENTIFICATION
10-
* $Header: /cvsroot/pgsql/src/backend/storage/ipc/shmem.c,v 1.27 1998/06/30 19:09:57 momjian Exp $
10+
* $Header: /cvsroot/pgsql/src/backend/storage/ipc/shmem.c,v 1.28 1998/07/21 06:17:35 vadim Exp $
1111
*
1212
*-------------------------------------------------------------------------
1313
*/
@@ -67,13 +67,17 @@
6767
#include"storage/proc.h"
6868
#include"utils/dynahash.h"
6969
#include"utils/hsearch.h"
70+
#include"utils/memutils.h"
71+
#include"access/transam.h"
7072

7173
/* shared memory global variables */
7274

7375
unsigned longShmemBase=0;/* start and end address of shared memory */
7476
staticunsigned longShmemEnd=0;
7577
staticunsigned longShmemSize=0;/* current size (and default) */
7678

79+
externVariableCacheShmemVariableCache;/* varsup.c */
80+
7781
SPINLOCKShmemLock;/* lock for shared memory allocation */
7882

7983
SPINLOCKShmemIndexLock;/* lock for shmem index access */
@@ -151,7 +155,6 @@ InitShmem(unsigned int key, unsigned int size)
151155
item;
152156
boolfound;
153157
IpcMemoryIdshmid;
154-
155158
/* if zero key, use default memory size */
156159
if (size)
157160
ShmemSize=size;
@@ -180,9 +183,12 @@ InitShmem(unsigned int key, unsigned int size)
180183
ShmemFreeStart= (unsigned long*)ShmemBase;
181184
/* next is a shmem pointer to the shmem index */
182185
ShmemIndexOffset=ShmemFreeStart+1;
186+
/* next is ShmemVariableCache */
187+
ShmemVariableCache= (VariableCache) (ShmemIndexOffset+1);
183188

184189
currFreeSpace+=
185-
sizeof(ShmemFreeStart)+sizeof(ShmemIndexOffset);
190+
sizeof(ShmemFreeStart)+sizeof(ShmemIndexOffset)+
191+
LONGALIGN(sizeof(VariableCacheData));
186192

187193
/*
188194
* bootstrap initialize spin locks so we can start to use the
@@ -196,7 +202,10 @@ InitShmem(unsigned int key, unsigned int size)
196202
* setup the global free space count
197203
*/
198204
if (ShmemBootstrap)
205+
{
199206
*ShmemFreeStart=currFreeSpace;
207+
memset (ShmemVariableCache,0,sizeof(*ShmemVariableCache));
208+
}
200209

201210
/* if ShmemFreeStart is NULL, then the allocator won't work */
202211
Assert(*ShmemFreeStart);

‎src/include/access/transam.h

Lines changed: 19 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@
66
*
77
* Copyright (c) 1994, Regents of the University of California
88
*
9-
* $Id: transam.h,v 1.14 1998/02/26 04:40:30 momjian Exp $
9+
* $Id: transam.h,v 1.15 1998/07/21 06:17:39 vadim Exp $
1010
*
1111
* NOTES
1212
*Transaction System Version 101 now support proper oid
@@ -114,6 +114,24 @@ typedef struct VariableRelationContentsData
114114

115115
typedefVariableRelationContentsData*VariableRelationContents;
116116

117+
/*
118+
* VariableCache is placed in shmem and used by backends to
119+
* get next available XID & OID without access to
120+
* variable relation. Actually, I would like to have two
121+
* different on-disk storages for next XID and OID...
122+
* But hoping that someday we will use per database OID
123+
* generator I leaved this as is.- vadim 07/21/98
124+
*/
125+
typedefstructVariableCacheData
126+
{
127+
uint32xid_count;
128+
TransactionIdnextXid;
129+
uint32oid_count;/* not implemented, yet */
130+
OidnextOid;
131+
}VariableCacheData;
132+
133+
typedefVariableCacheData*VariableCache;
134+
117135
/* ----------------
118136
*extern declarations
119137
* ----------------

0 commit comments

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