Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
P
Postgres FD Implementation
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Analytics
Analytics
CI / CD
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
Abuhujair Javed
Postgres FD Implementation
Commits
5afe1714
Commit
5afe1714
authored
Jul 21, 1998
by
Vadim B. Mikheev
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
VariableCache (next XID generator) is placed in shmem.
parent
224a62c5
Changes
3
Hide whitespace changes
Inline
Side-by-side
Showing
3 changed files
with
50 additions
and
73 deletions
+50
-73
src/backend/access/transam/varsup.c
src/backend/access/transam/varsup.c
+19
-69
src/backend/storage/ipc/shmem.c
src/backend/storage/ipc/shmem.c
+12
-3
src/include/access/transam.h
src/include/access/transam.h
+19
-1
No files found.
src/backend/access/transam/varsup.c
View file @
5afe1714
...
...
@@ -7,7 +7,7 @@
*
*
* IDENTIFICATION
* $Header: /cvsroot/pgsql/src/backend/access/transam/varsup.c,v 1.1
5 1998/01/07 21:02:21 momjian
Exp $
* $Header: /cvsroot/pgsql/src/backend/access/transam/varsup.c,v 1.1
6 1998/07/21 06:17:13 vadim
Exp $
*
*-------------------------------------------------------------------------
*/
...
...
@@ -31,6 +31,8 @@ static void VariableRelationPutNextOid(Oid *oidP);
*/
int
OidGenLockId
;
VariableCache
ShmemVariableCache
=
NULL
;
/* ----------------------------------------------------------------
* variable relation query/update routines
* ----------------------------------------------------------------
...
...
@@ -258,16 +260,7 @@ VariableRelationPutNextOid(Oid *oidP)
* In the version 2 transaction system, transaction id's are
* restricted in several ways.
*
* First, all transaction id's are even numbers (4, 88, 121342, etc).
* This means the binary representation of the number will never
* have the least significent bit set. This bit is reserved to
* indicate that the transaction id does not in fact hold an XID,
* but rather a commit time. This makes it possible for the
* vaccuum daemon to disgard information from the log and time
* relations for committed tuples. This is important when archiving
* tuples to an optical disk because tuples with commit times
* stored in their xid fields will not need to consult the log
* and time relations.
* -- Old comments removed --
*
* Second, since we may someday preform compression of the data
* in the log and time relations, we cause the numbering of the
...
...
@@ -276,32 +269,16 @@ VariableRelationPutNextOid(Oid *oidP)
* transaction id's 0 - 510 will never be used. This space is
* in fact used to store the version number of the postgres
* transaction log and will someday store compression information
* about the log.
*
* Lastly, rather then access the variable relation each time
* a backend requests a new transction id, we "prefetch" 32
* transaction id's by incrementing the nextXid stored in the
* var relation by 64 (remember only even xid's are legal) and then
* returning these id's one at a time until they are exhausted.
* This means we reduce the number of accesses to the variable
* relation by 32 for each backend.
*
* Note: 32 has no special significance. We don't want the
* number to be too large because if when the backend
* terminates, we lose the xid's we cached.
* about the log. -- this is also old comments...
*
* ----------------
*/
#define VAR_XID_PREFETCH 32
static
int
prefetched_xid_count
=
0
;
static
TransactionId
next_prefetched_xid
;
#define VAR_XID_PREFETCH 1024
void
GetNewTransactionId
(
TransactionId
*
xid
)
{
TransactionId
nextid
;
/* ----------------
* during bootstrap initialization, we return the special
...
...
@@ -314,51 +291,24 @@ GetNewTransactionId(TransactionId *xid)
return
;
}
/* ----------------
* if we run out of prefetched xids, then we get some
* more before handing them out to the caller.
* ----------------
*/
if
(
prefetched_xid_count
==
0
)
SpinAcquire
(
OidGenLockId
);
/* not good for concurrency... */
if
(
ShmemVariableCache
->
xid_count
==
0
)
{
/* ----------------
* obtain exclusive access to the variable relation page
*
* get the "next" xid from the variable relation
* and save it in the prefetched id.
* ----------------
*/
SpinAcquire
(
OidGenLockId
);
TransactionId
nextid
;
VariableRelationGetNextXid
(
&
nextid
);
TransactionIdStore
(
nextid
,
&
next_prefetched_xid
);
/* ----------------
* now increment the variable relation's next xid
* and reset the prefetched_xid_count. We multiply
* the id by two because our xid's are always even.
* ----------------
*/
prefetched_xid_count
=
VAR_XID_PREFETCH
;
TransactionIdAdd
(
&
nextid
,
prefetched_xid_count
);
TransactionIdStore
(
nextid
,
&
(
ShmemVariableCache
->
nextXid
));
ShmemVariableCache
->
xid_count
=
VAR_XID_PREFETCH
;
TransactionIdAdd
(
&
nextid
,
VAR_XID_PREFETCH
);
VariableRelationPutNextXid
(
nextid
);
SpinRelease
(
OidGenLockId
);
}
/* ----------------
* return the next prefetched xid in the pointer passed by
* the user and decrement the prefetch count. We add two
* to id we return the next time this is called because our
* transaction ids are always even.
*
* XXX Transaction Ids used to be even as the low order bit was
* used to determine commit status. This is no long true so
* we now use even and odd transaction ids. -mer 5/26/92
* ----------------
*/
TransactionIdStore
(
next_prefetched_xid
,
xid
);
TransactionIdAdd
(
&
next_prefetched_xid
,
1
);
prefetched_xid_count
--
;
TransactionIdStore
(
ShmemVariableCache
->
nextXid
,
xid
);
TransactionIdAdd
(
&
(
ShmemVariableCache
->
nextXid
),
1
);
(
ShmemVariableCache
->
xid_count
)
--
;
SpinRelease
(
OidGenLockId
);
}
/* ----------------------------------------------------------------
...
...
src/backend/storage/ipc/shmem.c
View file @
5afe1714
...
...
@@ -7,7 +7,7 @@
*
*
* IDENTIFICATION
* $Header: /cvsroot/pgsql/src/backend/storage/ipc/shmem.c,v 1.2
7 1998/06/30 19:09:57 momjian
Exp $
* $Header: /cvsroot/pgsql/src/backend/storage/ipc/shmem.c,v 1.2
8 1998/07/21 06:17:35 vadim
Exp $
*
*-------------------------------------------------------------------------
*/
...
...
@@ -67,6 +67,8 @@
#include "storage/proc.h"
#include "utils/dynahash.h"
#include "utils/hsearch.h"
#include "utils/memutils.h"
#include "access/transam.h"
/* shared memory global variables */
...
...
@@ -74,6 +76,8 @@ unsigned long ShmemBase = 0; /* start and end address of shared memory */
static
unsigned
long
ShmemEnd
=
0
;
static
unsigned
long
ShmemSize
=
0
;
/* current size (and default) */
extern
VariableCache
ShmemVariableCache
;
/* varsup.c */
SPINLOCK
ShmemLock
;
/* lock for shared memory allocation */
SPINLOCK
ShmemIndexLock
;
/* lock for shmem index access */
...
...
@@ -151,7 +155,6 @@ InitShmem(unsigned int key, unsigned int size)
item
;
bool
found
;
IpcMemoryId
shmid
;
/* if zero key, use default memory size */
if
(
size
)
ShmemSize
=
size
;
...
...
@@ -180,9 +183,12 @@ InitShmem(unsigned int key, unsigned int size)
ShmemFreeStart
=
(
unsigned
long
*
)
ShmemBase
;
/* next is a shmem pointer to the shmem index */
ShmemIndexOffset
=
ShmemFreeStart
+
1
;
/* next is ShmemVariableCache */
ShmemVariableCache
=
(
VariableCache
)
(
ShmemIndexOffset
+
1
);
currFreeSpace
+=
sizeof
(
ShmemFreeStart
)
+
sizeof
(
ShmemIndexOffset
);
sizeof
(
ShmemFreeStart
)
+
sizeof
(
ShmemIndexOffset
)
+
LONGALIGN
(
sizeof
(
VariableCacheData
));
/*
* bootstrap initialize spin locks so we can start to use the
...
...
@@ -196,7 +202,10 @@ InitShmem(unsigned int key, unsigned int size)
* setup the global free space count
*/
if
(
ShmemBootstrap
)
{
*
ShmemFreeStart
=
currFreeSpace
;
memset
(
ShmemVariableCache
,
0
,
sizeof
(
*
ShmemVariableCache
));
}
/* if ShmemFreeStart is NULL, then the allocator won't work */
Assert
(
*
ShmemFreeStart
);
...
...
src/include/access/transam.h
View file @
5afe1714
...
...
@@ -6,7 +6,7 @@
*
* Copyright (c) 1994, Regents of the University of California
*
* $Id: transam.h,v 1.1
4 1998/02/26 04:40:30 momjian
Exp $
* $Id: transam.h,v 1.1
5 1998/07/21 06:17:39 vadim
Exp $
*
* NOTES
* Transaction System Version 101 now support proper oid
...
...
@@ -114,6 +114,24 @@ typedef struct VariableRelationContentsData
typedef
VariableRelationContentsData
*
VariableRelationContents
;
/*
* VariableCache is placed in shmem and used by backends to
* get next available XID & OID without access to
* variable relation. Actually, I would like to have two
* different on-disk storages for next XID and OID...
* But hoping that someday we will use per database OID
* generator I leaved this as is. - vadim 07/21/98
*/
typedef
struct
VariableCacheData
{
uint32
xid_count
;
TransactionId
nextXid
;
uint32
oid_count
;
/* not implemented, yet */
Oid
nextOid
;
}
VariableCacheData
;
typedef
VariableCacheData
*
VariableCache
;
/* ----------------
* extern declarations
* ----------------
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment