1996-07-09 08:22:35 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* localbuf.c
|
2002-08-06 04:36:35 +02:00
|
|
|
* local buffer manager. Fast buffer manager for temporary tables,
|
|
|
|
* which never need to be WAL-logged or checkpointed, etc.
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2017-01-03 19:48:53 +01:00
|
|
|
* Portions Copyright (c) 1996-2017, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994-5, Regents of the University of California
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2000-11-30 20:06:37 +01:00
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/backend/storage/buffer/localbuf.c
|
2000-11-30 20:06:37 +01:00
|
|
|
*
|
1996-07-09 08:22:35 +02:00
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
2000-11-20 17:47:32 +01:00
|
|
|
#include "postgres.h"
|
2000-10-28 18:21:00 +02:00
|
|
|
|
Improve the situation for parallel query versus temp relations.
Transmit the leader's temp-namespace state to workers. This is important
because without it, the workers do not really have the same search path
as the leader. For example, there is no good reason (and no extant code
either) to prevent a worker from executing a temp function that the
leader created previously; but as things stood it would fail to find the
temp function, and then either fail or execute the wrong function entirely.
We still prohibit a worker from creating a temp namespace on its own.
In effect, a worker can only see the session's temp namespace if the leader
had created it before starting the worker, which seems like the right
semantics.
Also, transmit the leader's BackendId to workers, and arrange for workers
to use that when determining the physical file path of a temp relation
belonging to their session. While the original intent was to prevent such
accesses entirely, there were a number of holes in that, notably in places
like dbsize.c which assume they can safely access temp rels of other
sessions anyway. We might as well get this right, as a small down payment
on someday allowing workers to access the leader's temp tables. (With
this change, directly using "MyBackendId" as a relation or buffer backend
ID is deprecated; you should use BackendIdForTempRelations() instead.
I left a couple of such uses alone though, as they're not going to be
reachable in parallel workers until we do something about localbuf.c.)
Move the thou-shalt-not-access-thy-leader's-temp-tables prohibition down
into localbuf.c, which is where it actually matters, instead of having it
in relation_open(). This amounts to recognizing that access to temp
tables' catalog entries is perfectly safe in a worker, it's only the data
in local buffers that is problematic.
Having done all that, we can get rid of the test in has_parallel_hazard()
that says that use of a temp table's rowtype is unsafe in parallel workers.
That test was unduly expensive, and if we really did need such a
prohibition, that was not even close to being a bulletproof guard for it.
(For example, any user-defined function executed in a parallel worker
might have attempted such access.)
2016-06-10 02:16:11 +02:00
|
|
|
#include "access/parallel.h"
|
2008-11-11 15:17:02 +01:00
|
|
|
#include "catalog/catalog.h"
|
2009-12-15 05:57:48 +01:00
|
|
|
#include "executor/instrument.h"
|
2000-11-30 02:39:08 +01:00
|
|
|
#include "storage/buf_internals.h"
|
|
|
|
#include "storage/bufmgr.h"
|
2005-03-20 00:27:11 +01:00
|
|
|
#include "utils/guc.h"
|
2005-03-19 18:39:43 +01:00
|
|
|
#include "utils/memutils.h"
|
2012-08-29 00:02:07 +02:00
|
|
|
#include "utils/resowner_private.h"
|
1996-07-09 08:22:35 +02:00
|
|
|
|
1997-04-18 04:53:37 +02:00
|
|
|
|
2002-08-06 04:36:35 +02:00
|
|
|
/*#define LBDEBUG*/
|
|
|
|
|
2005-03-19 18:39:43 +01:00
|
|
|
/* entry for buffer lookup hashtable */
|
|
|
|
typedef struct
|
|
|
|
{
|
|
|
|
BufferTag key; /* Tag of a disk page */
|
|
|
|
int id; /* Associated local buffer's index */
|
|
|
|
} LocalBufferLookupEnt;
|
|
|
|
|
2005-03-04 21:21:07 +01:00
|
|
|
/* Note: this macro only works on local buffers, not shared ones! */
|
2005-10-15 04:49:52 +02:00
|
|
|
#define LocalBufHdrGetBlock(bufHdr) \
|
2005-03-04 21:21:07 +01:00
|
|
|
LocalBufferBlockPointers[-((bufHdr)->buf_id + 2)]
|
|
|
|
|
2005-03-19 18:39:43 +01:00
|
|
|
int NLocBuffer = 0; /* until buffers are initialized */
|
2002-08-06 04:36:35 +02:00
|
|
|
|
1997-09-08 04:41:22 +02:00
|
|
|
BufferDesc *LocalBufferDescriptors = NULL;
|
2000-11-30 02:39:08 +01:00
|
|
|
Block *LocalBufferBlockPointers = NULL;
|
2004-04-22 09:21:55 +02:00
|
|
|
int32 *LocalRefCount = NULL;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
1997-09-08 04:41:22 +02:00
|
|
|
static int nextFreeLocalBuf = 0;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2005-03-19 18:39:43 +01:00
|
|
|
static HTAB *LocalBufHash = NULL;
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2005-03-20 00:27:11 +01:00
|
|
|
static void InitLocalBuffers(void);
|
2006-12-27 23:31:54 +01:00
|
|
|
static Block GetLocalBufferStorage(void);
|
2005-03-20 00:27:11 +01:00
|
|
|
|
|
|
|
|
2009-01-12 06:10:45 +01:00
|
|
|
/*
|
|
|
|
* LocalPrefetchBuffer -
|
|
|
|
* initiate asynchronous read of a block of a relation
|
|
|
|
*
|
|
|
|
* Do PrefetchBuffer's work for temporary relations.
|
|
|
|
* No-op if prefetching isn't compiled in.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
LocalPrefetchBuffer(SMgrRelation smgr, ForkNumber forkNum,
|
|
|
|
BlockNumber blockNum)
|
|
|
|
{
|
|
|
|
#ifdef USE_PREFETCH
|
|
|
|
BufferTag newTag; /* identity of requested block */
|
|
|
|
LocalBufferLookupEnt *hresult;
|
|
|
|
|
2010-08-13 22:10:54 +02:00
|
|
|
INIT_BUFFERTAG(newTag, smgr->smgr_rnode.node, forkNum, blockNum);
|
2009-01-12 06:10:45 +01:00
|
|
|
|
|
|
|
/* Initialize local buffers if first request in this session */
|
|
|
|
if (LocalBufHash == NULL)
|
|
|
|
InitLocalBuffers();
|
|
|
|
|
|
|
|
/* See if the desired buffer already exists */
|
|
|
|
hresult = (LocalBufferLookupEnt *)
|
|
|
|
hash_search(LocalBufHash, (void *) &newTag, HASH_FIND, NULL);
|
|
|
|
|
|
|
|
if (hresult)
|
|
|
|
{
|
|
|
|
/* Yes, so nothing to do */
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Not in buffers, so initiate prefetch */
|
|
|
|
smgrprefetch(smgr, forkNum, blockNum);
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* USE_PREFETCH */
|
2009-01-12 06:10:45 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*
|
|
|
|
* LocalBufferAlloc -
|
2005-03-19 18:39:43 +01:00
|
|
|
* Find or create a local buffer for the given page of the given relation.
|
2004-04-21 20:06:30 +02:00
|
|
|
*
|
|
|
|
* API is similar to bufmgr.c's BufferAlloc, except that we do not need
|
2014-05-06 18:12:18 +02:00
|
|
|
* to do any locking since this is all local. Also, IO_IN_PROGRESS
|
2007-05-30 22:12:03 +02:00
|
|
|
* does not get set. Lastly, we support only default access strategy
|
|
|
|
* (hence, usage_count is always advanced).
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
1997-09-08 04:41:22 +02:00
|
|
|
BufferDesc *
|
2008-08-11 13:05:11 +02:00
|
|
|
LocalBufferAlloc(SMgrRelation smgr, ForkNumber forkNum, BlockNumber blockNum,
|
|
|
|
bool *foundPtr)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2004-04-21 20:06:30 +02:00
|
|
|
BufferTag newTag; /* identity of requested block */
|
2005-03-19 18:39:43 +01:00
|
|
|
LocalBufferLookupEnt *hresult;
|
2004-04-21 20:06:30 +02:00
|
|
|
BufferDesc *bufHdr;
|
2005-03-19 18:39:43 +01:00
|
|
|
int b;
|
|
|
|
int trycounter;
|
|
|
|
bool found;
|
Allow Pin/UnpinBuffer to operate in a lockfree manner.
Pinning/Unpinning a buffer is a very frequent operation; especially in
read-mostly cache resident workloads. Benchmarking shows that in various
scenarios the spinlock protecting a buffer header's state becomes a
significant bottleneck. The problem can be reproduced with pgbench -S on
larger machines, but can be considerably worse for queries which touch
the same buffers over and over at a high frequency (e.g. nested loops
over a small inner table).
To allow atomic operations to be used, cram BufferDesc's flags,
usage_count, buf_hdr_lock, refcount into a single 32bit atomic variable;
that allows to manipulate them together using 32bit compare-and-swap
operations. This requires reducing MAX_BACKENDS to 2^18-1 (which could
be lifted by using a 64bit field, but it's not a realistic configuration
atm).
As not all operations can easily implemented in a lockfree manner,
implement the previous buf_hdr_lock via a flag bit in the atomic
variable. That way we can continue to lock the header in places where
it's needed, but can get away without acquiring it in the more frequent
hot-paths. There's some additional operations which can be done without
the lock, but aren't in this patch; but the most important places are
covered.
As bufmgr.c now essentially re-implements spinlocks, abstract the delay
logic from s_lock.c into something more generic. It now has already two
users, and more are coming up; there's a follupw patch for lwlock.c at
least.
This patch is based on a proof-of-concept written by me, which Alexander
Korotkov made into a fully working patch; the committed version is again
revised by me. Benchmarking and testing has, amongst others, been
provided by Dilip Kumar, Alexander Korotkov, Robert Haas.
On a large x86 system improvements for readonly pgbench, with a high
client count, of a factor of 8 have been observed.
Author: Alexander Korotkov and Andres Freund
Discussion: 2400449.GjM57CE0Yg@dinodell
2016-04-11 05:12:32 +02:00
|
|
|
uint32 buf_state;
|
2004-04-21 20:06:30 +02:00
|
|
|
|
2010-08-13 22:10:54 +02:00
|
|
|
INIT_BUFFERTAG(newTag, smgr->smgr_rnode.node, forkNum, blockNum);
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2005-03-20 00:27:11 +01:00
|
|
|
/* Initialize local buffers if first request in this session */
|
|
|
|
if (LocalBufHash == NULL)
|
|
|
|
InitLocalBuffers();
|
|
|
|
|
2005-03-19 18:39:43 +01:00
|
|
|
/* See if the desired buffer already exists */
|
|
|
|
hresult = (LocalBufferLookupEnt *)
|
|
|
|
hash_search(LocalBufHash, (void *) &newTag, HASH_FIND, NULL);
|
|
|
|
|
|
|
|
if (hresult)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2005-03-19 18:39:43 +01:00
|
|
|
b = hresult->id;
|
Align buffer descriptors to cache line boundaries.
Benchmarks has shown that aligning the buffer descriptor array to
cache lines is important for scalability; especially on bigger,
multi-socket, machines.
Currently the array sometimes already happens to be aligned by
happenstance, depending how large previous shared memory allocations
were. That can lead to wildly varying performance results after minor
configuration changes.
In addition to aligning the start of descriptor array, also force the
size of individual descriptors to be of a common cache line size (64
bytes). That happens to already be the case on 64bit platforms, but
this way we can change the struct BufferDesc more easily.
As the alignment primarily matters in highly concurrent workloads
which probably all are 64bit these days, and the space wastage of
element alignment would be a bit more noticeable on 32bit systems, we
don't force the stride to be cacheline sized on 32bit platforms for
now. If somebody does actual performance testing, we can reevaluate
that decision by changing the definition of BUFFERDESC_PADDED_SIZE.
Discussion: 20140202151319.GD32123@awork2.anarazel.de
Per discussion with Bruce Momjan, Tom Lane, Robert Haas, and Peter
Geoghegan.
2015-01-29 17:49:03 +01:00
|
|
|
bufHdr = GetLocalBufferDescriptor(b);
|
2005-03-19 18:39:43 +01:00
|
|
|
Assert(BUFFERTAGS_EQUAL(bufHdr->tag, newTag));
|
1996-07-09 08:22:35 +02:00
|
|
|
#ifdef LBDEBUG
|
2008-11-27 08:38:01 +01:00
|
|
|
fprintf(stderr, "LB ALLOC (%u,%d,%d) %d\n",
|
2010-08-13 22:10:54 +02:00
|
|
|
smgr->smgr_rnode.node.relNode, forkNum, blockNum, -b - 1);
|
1997-09-07 07:04:48 +02:00
|
|
|
#endif
|
Allow Pin/UnpinBuffer to operate in a lockfree manner.
Pinning/Unpinning a buffer is a very frequent operation; especially in
read-mostly cache resident workloads. Benchmarking shows that in various
scenarios the spinlock protecting a buffer header's state becomes a
significant bottleneck. The problem can be reproduced with pgbench -S on
larger machines, but can be considerably worse for queries which touch
the same buffers over and over at a high frequency (e.g. nested loops
over a small inner table).
To allow atomic operations to be used, cram BufferDesc's flags,
usage_count, buf_hdr_lock, refcount into a single 32bit atomic variable;
that allows to manipulate them together using 32bit compare-and-swap
operations. This requires reducing MAX_BACKENDS to 2^18-1 (which could
be lifted by using a 64bit field, but it's not a realistic configuration
atm).
As not all operations can easily implemented in a lockfree manner,
implement the previous buf_hdr_lock via a flag bit in the atomic
variable. That way we can continue to lock the header in places where
it's needed, but can get away without acquiring it in the more frequent
hot-paths. There's some additional operations which can be done without
the lock, but aren't in this patch; but the most important places are
covered.
As bufmgr.c now essentially re-implements spinlocks, abstract the delay
logic from s_lock.c into something more generic. It now has already two
users, and more are coming up; there's a follupw patch for lwlock.c at
least.
This patch is based on a proof-of-concept written by me, which Alexander
Korotkov made into a fully working patch; the committed version is again
revised by me. Benchmarking and testing has, amongst others, been
provided by Dilip Kumar, Alexander Korotkov, Robert Haas.
On a large x86 system improvements for readonly pgbench, with a high
client count, of a factor of 8 have been observed.
Author: Alexander Korotkov and Andres Freund
Discussion: 2400449.GjM57CE0Yg@dinodell
2016-04-11 05:12:32 +02:00
|
|
|
buf_state = pg_atomic_read_u32(&bufHdr->state);
|
|
|
|
|
2007-05-30 22:12:03 +02:00
|
|
|
/* this part is equivalent to PinBuffer for a shared buffer */
|
|
|
|
if (LocalRefCount[b] == 0)
|
|
|
|
{
|
Allow Pin/UnpinBuffer to operate in a lockfree manner.
Pinning/Unpinning a buffer is a very frequent operation; especially in
read-mostly cache resident workloads. Benchmarking shows that in various
scenarios the spinlock protecting a buffer header's state becomes a
significant bottleneck. The problem can be reproduced with pgbench -S on
larger machines, but can be considerably worse for queries which touch
the same buffers over and over at a high frequency (e.g. nested loops
over a small inner table).
To allow atomic operations to be used, cram BufferDesc's flags,
usage_count, buf_hdr_lock, refcount into a single 32bit atomic variable;
that allows to manipulate them together using 32bit compare-and-swap
operations. This requires reducing MAX_BACKENDS to 2^18-1 (which could
be lifted by using a 64bit field, but it's not a realistic configuration
atm).
As not all operations can easily implemented in a lockfree manner,
implement the previous buf_hdr_lock via a flag bit in the atomic
variable. That way we can continue to lock the header in places where
it's needed, but can get away without acquiring it in the more frequent
hot-paths. There's some additional operations which can be done without
the lock, but aren't in this patch; but the most important places are
covered.
As bufmgr.c now essentially re-implements spinlocks, abstract the delay
logic from s_lock.c into something more generic. It now has already two
users, and more are coming up; there's a follupw patch for lwlock.c at
least.
This patch is based on a proof-of-concept written by me, which Alexander
Korotkov made into a fully working patch; the committed version is again
revised by me. Benchmarking and testing has, amongst others, been
provided by Dilip Kumar, Alexander Korotkov, Robert Haas.
On a large x86 system improvements for readonly pgbench, with a high
client count, of a factor of 8 have been observed.
Author: Alexander Korotkov and Andres Freund
Discussion: 2400449.GjM57CE0Yg@dinodell
2016-04-11 05:12:32 +02:00
|
|
|
if (BUF_STATE_GET_USAGECOUNT(buf_state) < BM_MAX_USAGE_COUNT)
|
|
|
|
{
|
|
|
|
buf_state += BUF_USAGECOUNT_ONE;
|
Fix fallback implementation of pg_atomic_write_u32().
I somehow had assumed that in the spinlock (in turn possibly using
semaphores) based fallback atomics implementation 32 bit writes could be
done without a lock. As far as the write goes that's correct, since
postgres supports only platforms with single-copy atomicity for aligned
32bit writes. But writing without holding the spinlock breaks
read-modify-write operations like pg_atomic_compare_exchange_u32(),
since they'll potentially "miss" a concurrent write, which can't happen
in actual hardware implementations.
In 9.6+ when using the fallback atomics implementation this could lead
to buffer header locks not being properly marked as released, and
potentially some related state corruption. I don't see a related danger
in 9.5 (earliest release with the API), because pg_atomic_write_u32()
wasn't used in a concurrent manner there.
The state variable of local buffers, before this change, were
manipulated using pg_atomic_write_u32(), to avoid unnecessary
synchronization overhead. As that'd not be the case anymore, introduce
and use pg_atomic_unlocked_write_u32(), which does not correctly
interact with RMW operations.
This bug only caused issues when postgres is compiled on platforms
without atomics support (i.e. no common new platform), or when compiled
with --disable-atomics, which explains why this wasn't noticed in
testing.
Reported-By: Tom Lane
Discussion: <14947.1475690465@sss.pgh.pa.us>
Backpatch: 9.5-, where the atomic operations API was introduced.
2016-10-08 01:55:15 +02:00
|
|
|
pg_atomic_unlocked_write_u32(&bufHdr->state, buf_state);
|
Allow Pin/UnpinBuffer to operate in a lockfree manner.
Pinning/Unpinning a buffer is a very frequent operation; especially in
read-mostly cache resident workloads. Benchmarking shows that in various
scenarios the spinlock protecting a buffer header's state becomes a
significant bottleneck. The problem can be reproduced with pgbench -S on
larger machines, but can be considerably worse for queries which touch
the same buffers over and over at a high frequency (e.g. nested loops
over a small inner table).
To allow atomic operations to be used, cram BufferDesc's flags,
usage_count, buf_hdr_lock, refcount into a single 32bit atomic variable;
that allows to manipulate them together using 32bit compare-and-swap
operations. This requires reducing MAX_BACKENDS to 2^18-1 (which could
be lifted by using a 64bit field, but it's not a realistic configuration
atm).
As not all operations can easily implemented in a lockfree manner,
implement the previous buf_hdr_lock via a flag bit in the atomic
variable. That way we can continue to lock the header in places where
it's needed, but can get away without acquiring it in the more frequent
hot-paths. There's some additional operations which can be done without
the lock, but aren't in this patch; but the most important places are
covered.
As bufmgr.c now essentially re-implements spinlocks, abstract the delay
logic from s_lock.c into something more generic. It now has already two
users, and more are coming up; there's a follupw patch for lwlock.c at
least.
This patch is based on a proof-of-concept written by me, which Alexander
Korotkov made into a fully working patch; the committed version is again
revised by me. Benchmarking and testing has, amongst others, been
provided by Dilip Kumar, Alexander Korotkov, Robert Haas.
On a large x86 system improvements for readonly pgbench, with a high
client count, of a factor of 8 have been observed.
Author: Alexander Korotkov and Andres Freund
Discussion: 2400449.GjM57CE0Yg@dinodell
2016-04-11 05:12:32 +02:00
|
|
|
}
|
2007-05-30 22:12:03 +02:00
|
|
|
}
|
2005-03-19 18:39:43 +01:00
|
|
|
LocalRefCount[b]++;
|
|
|
|
ResourceOwnerRememberBuffer(CurrentResourceOwner,
|
|
|
|
BufferDescriptorGetBuffer(bufHdr));
|
Allow Pin/UnpinBuffer to operate in a lockfree manner.
Pinning/Unpinning a buffer is a very frequent operation; especially in
read-mostly cache resident workloads. Benchmarking shows that in various
scenarios the spinlock protecting a buffer header's state becomes a
significant bottleneck. The problem can be reproduced with pgbench -S on
larger machines, but can be considerably worse for queries which touch
the same buffers over and over at a high frequency (e.g. nested loops
over a small inner table).
To allow atomic operations to be used, cram BufferDesc's flags,
usage_count, buf_hdr_lock, refcount into a single 32bit atomic variable;
that allows to manipulate them together using 32bit compare-and-swap
operations. This requires reducing MAX_BACKENDS to 2^18-1 (which could
be lifted by using a 64bit field, but it's not a realistic configuration
atm).
As not all operations can easily implemented in a lockfree manner,
implement the previous buf_hdr_lock via a flag bit in the atomic
variable. That way we can continue to lock the header in places where
it's needed, but can get away without acquiring it in the more frequent
hot-paths. There's some additional operations which can be done without
the lock, but aren't in this patch; but the most important places are
covered.
As bufmgr.c now essentially re-implements spinlocks, abstract the delay
logic from s_lock.c into something more generic. It now has already two
users, and more are coming up; there's a follupw patch for lwlock.c at
least.
This patch is based on a proof-of-concept written by me, which Alexander
Korotkov made into a fully working patch; the committed version is again
revised by me. Benchmarking and testing has, amongst others, been
provided by Dilip Kumar, Alexander Korotkov, Robert Haas.
On a large x86 system improvements for readonly pgbench, with a high
client count, of a factor of 8 have been observed.
Author: Alexander Korotkov and Andres Freund
Discussion: 2400449.GjM57CE0Yg@dinodell
2016-04-11 05:12:32 +02:00
|
|
|
if (buf_state & BM_VALID)
|
2017-08-16 06:22:32 +02:00
|
|
|
*foundPtr = true;
|
2005-03-19 18:39:43 +01:00
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Previous read attempt must have failed; try again */
|
2017-08-16 06:22:32 +02:00
|
|
|
*foundPtr = false;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
2005-03-19 18:39:43 +01:00
|
|
|
return bufHdr;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef LBDEBUG
|
2008-11-27 08:38:01 +01:00
|
|
|
fprintf(stderr, "LB ALLOC (%u,%d,%d) %d\n",
|
2011-04-10 17:42:00 +02:00
|
|
|
smgr->smgr_rnode.node.relNode, forkNum, blockNum,
|
|
|
|
-nextFreeLocalBuf - 1);
|
1997-09-07 07:04:48 +02:00
|
|
|
#endif
|
|
|
|
|
2005-03-04 21:21:07 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Need to get a new buffer. We use a clock sweep algorithm (essentially
|
|
|
|
* the same as what freelist.c does now...)
|
2005-03-04 21:21:07 +01:00
|
|
|
*/
|
|
|
|
trycounter = NLocBuffer;
|
|
|
|
for (;;)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2005-03-19 18:39:43 +01:00
|
|
|
b = nextFreeLocalBuf;
|
2005-03-04 21:21:07 +01:00
|
|
|
|
|
|
|
if (++nextFreeLocalBuf >= NLocBuffer)
|
|
|
|
nextFreeLocalBuf = 0;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
Align buffer descriptors to cache line boundaries.
Benchmarks has shown that aligning the buffer descriptor array to
cache lines is important for scalability; especially on bigger,
multi-socket, machines.
Currently the array sometimes already happens to be aligned by
happenstance, depending how large previous shared memory allocations
were. That can lead to wildly varying performance results after minor
configuration changes.
In addition to aligning the start of descriptor array, also force the
size of individual descriptors to be of a common cache line size (64
bytes). That happens to already be the case on 64bit platforms, but
this way we can change the struct BufferDesc more easily.
As the alignment primarily matters in highly concurrent workloads
which probably all are 64bit these days, and the space wastage of
element alignment would be a bit more noticeable on 32bit systems, we
don't force the stride to be cacheline sized on 32bit platforms for
now. If somebody does actual performance testing, we can reevaluate
that decision by changing the definition of BUFFERDESC_PADDED_SIZE.
Discussion: 20140202151319.GD32123@awork2.anarazel.de
Per discussion with Bruce Momjan, Tom Lane, Robert Haas, and Peter
Geoghegan.
2015-01-29 17:49:03 +01:00
|
|
|
bufHdr = GetLocalBufferDescriptor(b);
|
2005-03-04 21:21:07 +01:00
|
|
|
|
2007-05-30 22:12:03 +02:00
|
|
|
if (LocalRefCount[b] == 0)
|
2005-03-04 21:21:07 +01:00
|
|
|
{
|
Allow Pin/UnpinBuffer to operate in a lockfree manner.
Pinning/Unpinning a buffer is a very frequent operation; especially in
read-mostly cache resident workloads. Benchmarking shows that in various
scenarios the spinlock protecting a buffer header's state becomes a
significant bottleneck. The problem can be reproduced with pgbench -S on
larger machines, but can be considerably worse for queries which touch
the same buffers over and over at a high frequency (e.g. nested loops
over a small inner table).
To allow atomic operations to be used, cram BufferDesc's flags,
usage_count, buf_hdr_lock, refcount into a single 32bit atomic variable;
that allows to manipulate them together using 32bit compare-and-swap
operations. This requires reducing MAX_BACKENDS to 2^18-1 (which could
be lifted by using a 64bit field, but it's not a realistic configuration
atm).
As not all operations can easily implemented in a lockfree manner,
implement the previous buf_hdr_lock via a flag bit in the atomic
variable. That way we can continue to lock the header in places where
it's needed, but can get away without acquiring it in the more frequent
hot-paths. There's some additional operations which can be done without
the lock, but aren't in this patch; but the most important places are
covered.
As bufmgr.c now essentially re-implements spinlocks, abstract the delay
logic from s_lock.c into something more generic. It now has already two
users, and more are coming up; there's a follupw patch for lwlock.c at
least.
This patch is based on a proof-of-concept written by me, which Alexander
Korotkov made into a fully working patch; the committed version is again
revised by me. Benchmarking and testing has, amongst others, been
provided by Dilip Kumar, Alexander Korotkov, Robert Haas.
On a large x86 system improvements for readonly pgbench, with a high
client count, of a factor of 8 have been observed.
Author: Alexander Korotkov and Andres Freund
Discussion: 2400449.GjM57CE0Yg@dinodell
2016-04-11 05:12:32 +02:00
|
|
|
buf_state = pg_atomic_read_u32(&bufHdr->state);
|
|
|
|
|
|
|
|
if (BUF_STATE_GET_USAGECOUNT(buf_state) > 0)
|
2007-05-30 22:12:03 +02:00
|
|
|
{
|
Allow Pin/UnpinBuffer to operate in a lockfree manner.
Pinning/Unpinning a buffer is a very frequent operation; especially in
read-mostly cache resident workloads. Benchmarking shows that in various
scenarios the spinlock protecting a buffer header's state becomes a
significant bottleneck. The problem can be reproduced with pgbench -S on
larger machines, but can be considerably worse for queries which touch
the same buffers over and over at a high frequency (e.g. nested loops
over a small inner table).
To allow atomic operations to be used, cram BufferDesc's flags,
usage_count, buf_hdr_lock, refcount into a single 32bit atomic variable;
that allows to manipulate them together using 32bit compare-and-swap
operations. This requires reducing MAX_BACKENDS to 2^18-1 (which could
be lifted by using a 64bit field, but it's not a realistic configuration
atm).
As not all operations can easily implemented in a lockfree manner,
implement the previous buf_hdr_lock via a flag bit in the atomic
variable. That way we can continue to lock the header in places where
it's needed, but can get away without acquiring it in the more frequent
hot-paths. There's some additional operations which can be done without
the lock, but aren't in this patch; but the most important places are
covered.
As bufmgr.c now essentially re-implements spinlocks, abstract the delay
logic from s_lock.c into something more generic. It now has already two
users, and more are coming up; there's a follupw patch for lwlock.c at
least.
This patch is based on a proof-of-concept written by me, which Alexander
Korotkov made into a fully working patch; the committed version is again
revised by me. Benchmarking and testing has, amongst others, been
provided by Dilip Kumar, Alexander Korotkov, Robert Haas.
On a large x86 system improvements for readonly pgbench, with a high
client count, of a factor of 8 have been observed.
Author: Alexander Korotkov and Andres Freund
Discussion: 2400449.GjM57CE0Yg@dinodell
2016-04-11 05:12:32 +02:00
|
|
|
buf_state -= BUF_USAGECOUNT_ONE;
|
Fix fallback implementation of pg_atomic_write_u32().
I somehow had assumed that in the spinlock (in turn possibly using
semaphores) based fallback atomics implementation 32 bit writes could be
done without a lock. As far as the write goes that's correct, since
postgres supports only platforms with single-copy atomicity for aligned
32bit writes. But writing without holding the spinlock breaks
read-modify-write operations like pg_atomic_compare_exchange_u32(),
since they'll potentially "miss" a concurrent write, which can't happen
in actual hardware implementations.
In 9.6+ when using the fallback atomics implementation this could lead
to buffer header locks not being properly marked as released, and
potentially some related state corruption. I don't see a related danger
in 9.5 (earliest release with the API), because pg_atomic_write_u32()
wasn't used in a concurrent manner there.
The state variable of local buffers, before this change, were
manipulated using pg_atomic_write_u32(), to avoid unnecessary
synchronization overhead. As that'd not be the case anymore, introduce
and use pg_atomic_unlocked_write_u32(), which does not correctly
interact with RMW operations.
This bug only caused issues when postgres is compiled on platforms
without atomics support (i.e. no common new platform), or when compiled
with --disable-atomics, which explains why this wasn't noticed in
testing.
Reported-By: Tom Lane
Discussion: <14947.1475690465@sss.pgh.pa.us>
Backpatch: 9.5-, where the atomic operations API was introduced.
2016-10-08 01:55:15 +02:00
|
|
|
pg_atomic_unlocked_write_u32(&bufHdr->state, buf_state);
|
2007-05-30 22:12:03 +02:00
|
|
|
trycounter = NLocBuffer;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Found a usable buffer */
|
|
|
|
LocalRefCount[b]++;
|
|
|
|
ResourceOwnerRememberBuffer(CurrentResourceOwner,
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
BufferDescriptorGetBuffer(bufHdr));
|
2007-05-30 22:12:03 +02:00
|
|
|
break;
|
|
|
|
}
|
2005-03-04 21:21:07 +01:00
|
|
|
}
|
|
|
|
else if (--trycounter == 0)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INSUFFICIENT_RESOURCES),
|
|
|
|
errmsg("no empty local buffer available")));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* this buffer is not referenced but it might still be dirty. if that's
|
|
|
|
* the case, write it out before reusing it!
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
Allow Pin/UnpinBuffer to operate in a lockfree manner.
Pinning/Unpinning a buffer is a very frequent operation; especially in
read-mostly cache resident workloads. Benchmarking shows that in various
scenarios the spinlock protecting a buffer header's state becomes a
significant bottleneck. The problem can be reproduced with pgbench -S on
larger machines, but can be considerably worse for queries which touch
the same buffers over and over at a high frequency (e.g. nested loops
over a small inner table).
To allow atomic operations to be used, cram BufferDesc's flags,
usage_count, buf_hdr_lock, refcount into a single 32bit atomic variable;
that allows to manipulate them together using 32bit compare-and-swap
operations. This requires reducing MAX_BACKENDS to 2^18-1 (which could
be lifted by using a 64bit field, but it's not a realistic configuration
atm).
As not all operations can easily implemented in a lockfree manner,
implement the previous buf_hdr_lock via a flag bit in the atomic
variable. That way we can continue to lock the header in places where
it's needed, but can get away without acquiring it in the more frequent
hot-paths. There's some additional operations which can be done without
the lock, but aren't in this patch; but the most important places are
covered.
As bufmgr.c now essentially re-implements spinlocks, abstract the delay
logic from s_lock.c into something more generic. It now has already two
users, and more are coming up; there's a follupw patch for lwlock.c at
least.
This patch is based on a proof-of-concept written by me, which Alexander
Korotkov made into a fully working patch; the committed version is again
revised by me. Benchmarking and testing has, amongst others, been
provided by Dilip Kumar, Alexander Korotkov, Robert Haas.
On a large x86 system improvements for readonly pgbench, with a high
client count, of a factor of 8 have been observed.
Author: Alexander Korotkov and Andres Freund
Discussion: 2400449.GjM57CE0Yg@dinodell
2016-04-11 05:12:32 +02:00
|
|
|
if (buf_state & BM_DIRTY)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2013-05-29 22:58:43 +02:00
|
|
|
SMgrRelation oreln;
|
|
|
|
Page localpage = (char *) LocalBufHdrGetBlock(bufHdr);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2004-02-10 02:55:27 +01:00
|
|
|
/* Find smgr relation for buffer */
|
2010-08-13 22:10:54 +02:00
|
|
|
oreln = smgropen(bufHdr->tag.rnode, MyBackendId);
|
2004-02-10 02:55:27 +01:00
|
|
|
|
2013-03-22 14:54:07 +01:00
|
|
|
PageSetChecksumInplace(localpage, bufHdr->tag.blockNum);
|
|
|
|
|
2004-02-10 02:55:27 +01:00
|
|
|
/* And write... */
|
2005-01-10 21:02:24 +01:00
|
|
|
smgrwrite(oreln,
|
2008-08-11 13:05:11 +02:00
|
|
|
bufHdr->tag.forkNum,
|
2004-02-10 02:55:27 +01:00
|
|
|
bufHdr->tag.blockNum,
|
2013-03-22 14:54:07 +01:00
|
|
|
localpage,
|
2010-08-13 22:10:54 +02:00
|
|
|
false);
|
1999-09-18 21:08:25 +02:00
|
|
|
|
2005-03-19 18:39:43 +01:00
|
|
|
/* Mark not-dirty now in case we error out below */
|
Allow Pin/UnpinBuffer to operate in a lockfree manner.
Pinning/Unpinning a buffer is a very frequent operation; especially in
read-mostly cache resident workloads. Benchmarking shows that in various
scenarios the spinlock protecting a buffer header's state becomes a
significant bottleneck. The problem can be reproduced with pgbench -S on
larger machines, but can be considerably worse for queries which touch
the same buffers over and over at a high frequency (e.g. nested loops
over a small inner table).
To allow atomic operations to be used, cram BufferDesc's flags,
usage_count, buf_hdr_lock, refcount into a single 32bit atomic variable;
that allows to manipulate them together using 32bit compare-and-swap
operations. This requires reducing MAX_BACKENDS to 2^18-1 (which could
be lifted by using a 64bit field, but it's not a realistic configuration
atm).
As not all operations can easily implemented in a lockfree manner,
implement the previous buf_hdr_lock via a flag bit in the atomic
variable. That way we can continue to lock the header in places where
it's needed, but can get away without acquiring it in the more frequent
hot-paths. There's some additional operations which can be done without
the lock, but aren't in this patch; but the most important places are
covered.
As bufmgr.c now essentially re-implements spinlocks, abstract the delay
logic from s_lock.c into something more generic. It now has already two
users, and more are coming up; there's a follupw patch for lwlock.c at
least.
This patch is based on a proof-of-concept written by me, which Alexander
Korotkov made into a fully working patch; the committed version is again
revised by me. Benchmarking and testing has, amongst others, been
provided by Dilip Kumar, Alexander Korotkov, Robert Haas.
On a large x86 system improvements for readonly pgbench, with a high
client count, of a factor of 8 have been observed.
Author: Alexander Korotkov and Andres Freund
Discussion: 2400449.GjM57CE0Yg@dinodell
2016-04-11 05:12:32 +02:00
|
|
|
buf_state &= ~BM_DIRTY;
|
Fix fallback implementation of pg_atomic_write_u32().
I somehow had assumed that in the spinlock (in turn possibly using
semaphores) based fallback atomics implementation 32 bit writes could be
done without a lock. As far as the write goes that's correct, since
postgres supports only platforms with single-copy atomicity for aligned
32bit writes. But writing without holding the spinlock breaks
read-modify-write operations like pg_atomic_compare_exchange_u32(),
since they'll potentially "miss" a concurrent write, which can't happen
in actual hardware implementations.
In 9.6+ when using the fallback atomics implementation this could lead
to buffer header locks not being properly marked as released, and
potentially some related state corruption. I don't see a related danger
in 9.5 (earliest release with the API), because pg_atomic_write_u32()
wasn't used in a concurrent manner there.
The state variable of local buffers, before this change, were
manipulated using pg_atomic_write_u32(), to avoid unnecessary
synchronization overhead. As that'd not be the case anymore, introduce
and use pg_atomic_unlocked_write_u32(), which does not correctly
interact with RMW operations.
This bug only caused issues when postgres is compiled on platforms
without atomics support (i.e. no common new platform), or when compiled
with --disable-atomics, which explains why this wasn't noticed in
testing.
Reported-By: Tom Lane
Discussion: <14947.1475690465@sss.pgh.pa.us>
Backpatch: 9.5-, where the atomic operations API was introduced.
2016-10-08 01:55:15 +02:00
|
|
|
pg_atomic_unlocked_write_u32(&bufHdr->state, buf_state);
|
2005-03-19 18:39:43 +01:00
|
|
|
|
2009-12-15 05:57:48 +01:00
|
|
|
pgBufferUsage.local_blks_written++;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2000-11-30 02:39:08 +01:00
|
|
|
* lazy memory allocation: allocate space on first use of a buffer.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2005-03-04 21:21:07 +01:00
|
|
|
if (LocalBufHdrGetBlock(bufHdr) == NULL)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2005-03-19 18:39:43 +01:00
|
|
|
/* Set pointer for use by BufferGetBlock() macro */
|
2006-12-27 23:31:54 +01:00
|
|
|
LocalBufHdrGetBlock(bufHdr) = GetLocalBufferStorage();
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
|
2005-03-19 18:39:43 +01:00
|
|
|
/*
|
|
|
|
* Update the hash table: remove old entry, if any, and make new one.
|
|
|
|
*/
|
Allow Pin/UnpinBuffer to operate in a lockfree manner.
Pinning/Unpinning a buffer is a very frequent operation; especially in
read-mostly cache resident workloads. Benchmarking shows that in various
scenarios the spinlock protecting a buffer header's state becomes a
significant bottleneck. The problem can be reproduced with pgbench -S on
larger machines, but can be considerably worse for queries which touch
the same buffers over and over at a high frequency (e.g. nested loops
over a small inner table).
To allow atomic operations to be used, cram BufferDesc's flags,
usage_count, buf_hdr_lock, refcount into a single 32bit atomic variable;
that allows to manipulate them together using 32bit compare-and-swap
operations. This requires reducing MAX_BACKENDS to 2^18-1 (which could
be lifted by using a 64bit field, but it's not a realistic configuration
atm).
As not all operations can easily implemented in a lockfree manner,
implement the previous buf_hdr_lock via a flag bit in the atomic
variable. That way we can continue to lock the header in places where
it's needed, but can get away without acquiring it in the more frequent
hot-paths. There's some additional operations which can be done without
the lock, but aren't in this patch; but the most important places are
covered.
As bufmgr.c now essentially re-implements spinlocks, abstract the delay
logic from s_lock.c into something more generic. It now has already two
users, and more are coming up; there's a follupw patch for lwlock.c at
least.
This patch is based on a proof-of-concept written by me, which Alexander
Korotkov made into a fully working patch; the committed version is again
revised by me. Benchmarking and testing has, amongst others, been
provided by Dilip Kumar, Alexander Korotkov, Robert Haas.
On a large x86 system improvements for readonly pgbench, with a high
client count, of a factor of 8 have been observed.
Author: Alexander Korotkov and Andres Freund
Discussion: 2400449.GjM57CE0Yg@dinodell
2016-04-11 05:12:32 +02:00
|
|
|
if (buf_state & BM_TAG_VALID)
|
2005-03-19 18:39:43 +01:00
|
|
|
{
|
|
|
|
hresult = (LocalBufferLookupEnt *)
|
|
|
|
hash_search(LocalBufHash, (void *) &bufHdr->tag,
|
|
|
|
HASH_REMOVE, NULL);
|
2005-10-15 04:49:52 +02:00
|
|
|
if (!hresult) /* shouldn't happen */
|
2005-03-19 18:39:43 +01:00
|
|
|
elog(ERROR, "local buffer hash table corrupted");
|
|
|
|
/* mark buffer invalid just in case hash insert fails */
|
|
|
|
CLEAR_BUFFERTAG(bufHdr->tag);
|
Allow Pin/UnpinBuffer to operate in a lockfree manner.
Pinning/Unpinning a buffer is a very frequent operation; especially in
read-mostly cache resident workloads. Benchmarking shows that in various
scenarios the spinlock protecting a buffer header's state becomes a
significant bottleneck. The problem can be reproduced with pgbench -S on
larger machines, but can be considerably worse for queries which touch
the same buffers over and over at a high frequency (e.g. nested loops
over a small inner table).
To allow atomic operations to be used, cram BufferDesc's flags,
usage_count, buf_hdr_lock, refcount into a single 32bit atomic variable;
that allows to manipulate them together using 32bit compare-and-swap
operations. This requires reducing MAX_BACKENDS to 2^18-1 (which could
be lifted by using a 64bit field, but it's not a realistic configuration
atm).
As not all operations can easily implemented in a lockfree manner,
implement the previous buf_hdr_lock via a flag bit in the atomic
variable. That way we can continue to lock the header in places where
it's needed, but can get away without acquiring it in the more frequent
hot-paths. There's some additional operations which can be done without
the lock, but aren't in this patch; but the most important places are
covered.
As bufmgr.c now essentially re-implements spinlocks, abstract the delay
logic from s_lock.c into something more generic. It now has already two
users, and more are coming up; there's a follupw patch for lwlock.c at
least.
This patch is based on a proof-of-concept written by me, which Alexander
Korotkov made into a fully working patch; the committed version is again
revised by me. Benchmarking and testing has, amongst others, been
provided by Dilip Kumar, Alexander Korotkov, Robert Haas.
On a large x86 system improvements for readonly pgbench, with a high
client count, of a factor of 8 have been observed.
Author: Alexander Korotkov and Andres Freund
Discussion: 2400449.GjM57CE0Yg@dinodell
2016-04-11 05:12:32 +02:00
|
|
|
buf_state &= ~(BM_VALID | BM_TAG_VALID);
|
Fix fallback implementation of pg_atomic_write_u32().
I somehow had assumed that in the spinlock (in turn possibly using
semaphores) based fallback atomics implementation 32 bit writes could be
done without a lock. As far as the write goes that's correct, since
postgres supports only platforms with single-copy atomicity for aligned
32bit writes. But writing without holding the spinlock breaks
read-modify-write operations like pg_atomic_compare_exchange_u32(),
since they'll potentially "miss" a concurrent write, which can't happen
in actual hardware implementations.
In 9.6+ when using the fallback atomics implementation this could lead
to buffer header locks not being properly marked as released, and
potentially some related state corruption. I don't see a related danger
in 9.5 (earliest release with the API), because pg_atomic_write_u32()
wasn't used in a concurrent manner there.
The state variable of local buffers, before this change, were
manipulated using pg_atomic_write_u32(), to avoid unnecessary
synchronization overhead. As that'd not be the case anymore, introduce
and use pg_atomic_unlocked_write_u32(), which does not correctly
interact with RMW operations.
This bug only caused issues when postgres is compiled on platforms
without atomics support (i.e. no common new platform), or when compiled
with --disable-atomics, which explains why this wasn't noticed in
testing.
Reported-By: Tom Lane
Discussion: <14947.1475690465@sss.pgh.pa.us>
Backpatch: 9.5-, where the atomic operations API was introduced.
2016-10-08 01:55:15 +02:00
|
|
|
pg_atomic_unlocked_write_u32(&bufHdr->state, buf_state);
|
2005-03-19 18:39:43 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
hresult = (LocalBufferLookupEnt *)
|
|
|
|
hash_search(LocalBufHash, (void *) &newTag, HASH_ENTER, &found);
|
2005-10-15 04:49:52 +02:00
|
|
|
if (found) /* shouldn't happen */
|
2005-03-19 18:39:43 +01:00
|
|
|
elog(ERROR, "local buffer hash table corrupted");
|
|
|
|
hresult->id = b;
|
|
|
|
|
2002-08-06 04:36:35 +02:00
|
|
|
/*
|
|
|
|
* it's all ours now.
|
|
|
|
*/
|
2004-04-21 20:06:30 +02:00
|
|
|
bufHdr->tag = newTag;
|
Allow Pin/UnpinBuffer to operate in a lockfree manner.
Pinning/Unpinning a buffer is a very frequent operation; especially in
read-mostly cache resident workloads. Benchmarking shows that in various
scenarios the spinlock protecting a buffer header's state becomes a
significant bottleneck. The problem can be reproduced with pgbench -S on
larger machines, but can be considerably worse for queries which touch
the same buffers over and over at a high frequency (e.g. nested loops
over a small inner table).
To allow atomic operations to be used, cram BufferDesc's flags,
usage_count, buf_hdr_lock, refcount into a single 32bit atomic variable;
that allows to manipulate them together using 32bit compare-and-swap
operations. This requires reducing MAX_BACKENDS to 2^18-1 (which could
be lifted by using a 64bit field, but it's not a realistic configuration
atm).
As not all operations can easily implemented in a lockfree manner,
implement the previous buf_hdr_lock via a flag bit in the atomic
variable. That way we can continue to lock the header in places where
it's needed, but can get away without acquiring it in the more frequent
hot-paths. There's some additional operations which can be done without
the lock, but aren't in this patch; but the most important places are
covered.
As bufmgr.c now essentially re-implements spinlocks, abstract the delay
logic from s_lock.c into something more generic. It now has already two
users, and more are coming up; there's a follupw patch for lwlock.c at
least.
This patch is based on a proof-of-concept written by me, which Alexander
Korotkov made into a fully working patch; the committed version is again
revised by me. Benchmarking and testing has, amongst others, been
provided by Dilip Kumar, Alexander Korotkov, Robert Haas.
On a large x86 system improvements for readonly pgbench, with a high
client count, of a factor of 8 have been observed.
Author: Alexander Korotkov and Andres Freund
Discussion: 2400449.GjM57CE0Yg@dinodell
2016-04-11 05:12:32 +02:00
|
|
|
buf_state &= ~(BM_VALID | BM_DIRTY | BM_JUST_DIRTIED | BM_IO_ERROR);
|
|
|
|
buf_state |= BM_TAG_VALID;
|
|
|
|
buf_state &= ~BUF_USAGECOUNT_MASK;
|
|
|
|
buf_state += BUF_USAGECOUNT_ONE;
|
Fix fallback implementation of pg_atomic_write_u32().
I somehow had assumed that in the spinlock (in turn possibly using
semaphores) based fallback atomics implementation 32 bit writes could be
done without a lock. As far as the write goes that's correct, since
postgres supports only platforms with single-copy atomicity for aligned
32bit writes. But writing without holding the spinlock breaks
read-modify-write operations like pg_atomic_compare_exchange_u32(),
since they'll potentially "miss" a concurrent write, which can't happen
in actual hardware implementations.
In 9.6+ when using the fallback atomics implementation this could lead
to buffer header locks not being properly marked as released, and
potentially some related state corruption. I don't see a related danger
in 9.5 (earliest release with the API), because pg_atomic_write_u32()
wasn't used in a concurrent manner there.
The state variable of local buffers, before this change, were
manipulated using pg_atomic_write_u32(), to avoid unnecessary
synchronization overhead. As that'd not be the case anymore, introduce
and use pg_atomic_unlocked_write_u32(), which does not correctly
interact with RMW operations.
This bug only caused issues when postgres is compiled on platforms
without atomics support (i.e. no common new platform), or when compiled
with --disable-atomics, which explains why this wasn't noticed in
testing.
Reported-By: Tom Lane
Discussion: <14947.1475690465@sss.pgh.pa.us>
Backpatch: 9.5-, where the atomic operations API was introduced.
2016-10-08 01:55:15 +02:00
|
|
|
pg_atomic_unlocked_write_u32(&bufHdr->state, buf_state);
|
2002-08-06 04:36:35 +02:00
|
|
|
|
2017-08-16 06:22:32 +02:00
|
|
|
*foundPtr = false;
|
1997-09-07 07:04:48 +02:00
|
|
|
return bufHdr;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2006-04-01 01:32:07 +02:00
|
|
|
* MarkLocalBufferDirty -
|
|
|
|
* mark a local buffer dirty
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2002-06-15 21:59:59 +02:00
|
|
|
void
|
2006-04-01 01:32:07 +02:00
|
|
|
MarkLocalBufferDirty(Buffer buffer)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
int bufid;
|
2005-03-04 21:21:07 +01:00
|
|
|
BufferDesc *bufHdr;
|
Allow Pin/UnpinBuffer to operate in a lockfree manner.
Pinning/Unpinning a buffer is a very frequent operation; especially in
read-mostly cache resident workloads. Benchmarking shows that in various
scenarios the spinlock protecting a buffer header's state becomes a
significant bottleneck. The problem can be reproduced with pgbench -S on
larger machines, but can be considerably worse for queries which touch
the same buffers over and over at a high frequency (e.g. nested loops
over a small inner table).
To allow atomic operations to be used, cram BufferDesc's flags,
usage_count, buf_hdr_lock, refcount into a single 32bit atomic variable;
that allows to manipulate them together using 32bit compare-and-swap
operations. This requires reducing MAX_BACKENDS to 2^18-1 (which could
be lifted by using a 64bit field, but it's not a realistic configuration
atm).
As not all operations can easily implemented in a lockfree manner,
implement the previous buf_hdr_lock via a flag bit in the atomic
variable. That way we can continue to lock the header in places where
it's needed, but can get away without acquiring it in the more frequent
hot-paths. There's some additional operations which can be done without
the lock, but aren't in this patch; but the most important places are
covered.
As bufmgr.c now essentially re-implements spinlocks, abstract the delay
logic from s_lock.c into something more generic. It now has already two
users, and more are coming up; there's a follupw patch for lwlock.c at
least.
This patch is based on a proof-of-concept written by me, which Alexander
Korotkov made into a fully working patch; the committed version is again
revised by me. Benchmarking and testing has, amongst others, been
provided by Dilip Kumar, Alexander Korotkov, Robert Haas.
On a large x86 system improvements for readonly pgbench, with a high
client count, of a factor of 8 have been observed.
Author: Alexander Korotkov and Andres Freund
Discussion: 2400449.GjM57CE0Yg@dinodell
2016-04-11 05:12:32 +02:00
|
|
|
uint32 buf_state;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
Assert(BufferIsLocal(buffer));
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
#ifdef LBDEBUG
|
2006-04-01 01:32:07 +02:00
|
|
|
fprintf(stderr, "LB DIRTY %d\n", buffer);
|
1997-09-07 07:04:48 +02:00
|
|
|
#endif
|
1996-07-09 08:22:35 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
bufid = -(buffer + 1);
|
2005-03-04 21:21:07 +01:00
|
|
|
|
|
|
|
Assert(LocalRefCount[bufid] > 0);
|
|
|
|
|
Align buffer descriptors to cache line boundaries.
Benchmarks has shown that aligning the buffer descriptor array to
cache lines is important for scalability; especially on bigger,
multi-socket, machines.
Currently the array sometimes already happens to be aligned by
happenstance, depending how large previous shared memory allocations
were. That can lead to wildly varying performance results after minor
configuration changes.
In addition to aligning the start of descriptor array, also force the
size of individual descriptors to be of a common cache line size (64
bytes). That happens to already be the case on 64bit platforms, but
this way we can change the struct BufferDesc more easily.
As the alignment primarily matters in highly concurrent workloads
which probably all are 64bit these days, and the space wastage of
element alignment would be a bit more noticeable on 32bit systems, we
don't force the stride to be cacheline sized on 32bit platforms for
now. If somebody does actual performance testing, we can reevaluate
that decision by changing the definition of BUFFERDESC_PADDED_SIZE.
Discussion: 20140202151319.GD32123@awork2.anarazel.de
Per discussion with Bruce Momjan, Tom Lane, Robert Haas, and Peter
Geoghegan.
2015-01-29 17:49:03 +01:00
|
|
|
bufHdr = GetLocalBufferDescriptor(bufid);
|
2012-02-23 02:33:05 +01:00
|
|
|
|
2016-04-14 00:28:29 +02:00
|
|
|
buf_state = pg_atomic_read_u32(&bufHdr->state);
|
2012-02-23 02:33:05 +01:00
|
|
|
|
Allow Pin/UnpinBuffer to operate in a lockfree manner.
Pinning/Unpinning a buffer is a very frequent operation; especially in
read-mostly cache resident workloads. Benchmarking shows that in various
scenarios the spinlock protecting a buffer header's state becomes a
significant bottleneck. The problem can be reproduced with pgbench -S on
larger machines, but can be considerably worse for queries which touch
the same buffers over and over at a high frequency (e.g. nested loops
over a small inner table).
To allow atomic operations to be used, cram BufferDesc's flags,
usage_count, buf_hdr_lock, refcount into a single 32bit atomic variable;
that allows to manipulate them together using 32bit compare-and-swap
operations. This requires reducing MAX_BACKENDS to 2^18-1 (which could
be lifted by using a 64bit field, but it's not a realistic configuration
atm).
As not all operations can easily implemented in a lockfree manner,
implement the previous buf_hdr_lock via a flag bit in the atomic
variable. That way we can continue to lock the header in places where
it's needed, but can get away without acquiring it in the more frequent
hot-paths. There's some additional operations which can be done without
the lock, but aren't in this patch; but the most important places are
covered.
As bufmgr.c now essentially re-implements spinlocks, abstract the delay
logic from s_lock.c into something more generic. It now has already two
users, and more are coming up; there's a follupw patch for lwlock.c at
least.
This patch is based on a proof-of-concept written by me, which Alexander
Korotkov made into a fully working patch; the committed version is again
revised by me. Benchmarking and testing has, amongst others, been
provided by Dilip Kumar, Alexander Korotkov, Robert Haas.
On a large x86 system improvements for readonly pgbench, with a high
client count, of a factor of 8 have been observed.
Author: Alexander Korotkov and Andres Freund
Discussion: 2400449.GjM57CE0Yg@dinodell
2016-04-11 05:12:32 +02:00
|
|
|
if (!(buf_state & BM_DIRTY))
|
|
|
|
pgBufferUsage.local_blks_dirtied++;
|
2016-04-14 00:28:29 +02:00
|
|
|
|
|
|
|
buf_state |= BM_DIRTY;
|
|
|
|
|
Fix fallback implementation of pg_atomic_write_u32().
I somehow had assumed that in the spinlock (in turn possibly using
semaphores) based fallback atomics implementation 32 bit writes could be
done without a lock. As far as the write goes that's correct, since
postgres supports only platforms with single-copy atomicity for aligned
32bit writes. But writing without holding the spinlock breaks
read-modify-write operations like pg_atomic_compare_exchange_u32(),
since they'll potentially "miss" a concurrent write, which can't happen
in actual hardware implementations.
In 9.6+ when using the fallback atomics implementation this could lead
to buffer header locks not being properly marked as released, and
potentially some related state corruption. I don't see a related danger
in 9.5 (earliest release with the API), because pg_atomic_write_u32()
wasn't used in a concurrent manner there.
The state variable of local buffers, before this change, were
manipulated using pg_atomic_write_u32(), to avoid unnecessary
synchronization overhead. As that'd not be the case anymore, introduce
and use pg_atomic_unlocked_write_u32(), which does not correctly
interact with RMW operations.
This bug only caused issues when postgres is compiled on platforms
without atomics support (i.e. no common new platform), or when compiled
with --disable-atomics, which explains why this wasn't noticed in
testing.
Reported-By: Tom Lane
Discussion: <14947.1475690465@sss.pgh.pa.us>
Backpatch: 9.5-, where the atomic operations API was introduced.
2016-10-08 01:55:15 +02:00
|
|
|
pg_atomic_unlocked_write_u32(&bufHdr->state, buf_state);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2005-11-17 18:42:02 +01:00
|
|
|
/*
|
|
|
|
* DropRelFileNodeLocalBuffers
|
|
|
|
* This function removes from the buffer pool all the pages of the
|
|
|
|
* specified relation that have block numbers >= firstDelBlock.
|
|
|
|
* (In particular, with firstDelBlock = 0, all pages are removed.)
|
|
|
|
* Dirty pages are simply dropped, without bothering to write them
|
2014-05-06 18:12:18 +02:00
|
|
|
* out first. Therefore, this is NOT rollback-able, and so should be
|
2005-11-17 18:42:02 +01:00
|
|
|
* used only with extreme caution!
|
|
|
|
*
|
|
|
|
* See DropRelFileNodeBuffers in bufmgr.c for more notes.
|
|
|
|
*/
|
|
|
|
void
|
2008-08-11 13:05:11 +02:00
|
|
|
DropRelFileNodeLocalBuffers(RelFileNode rnode, ForkNumber forkNum,
|
|
|
|
BlockNumber firstDelBlock)
|
2005-11-17 18:42:02 +01:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < NLocBuffer; i++)
|
|
|
|
{
|
Align buffer descriptors to cache line boundaries.
Benchmarks has shown that aligning the buffer descriptor array to
cache lines is important for scalability; especially on bigger,
multi-socket, machines.
Currently the array sometimes already happens to be aligned by
happenstance, depending how large previous shared memory allocations
were. That can lead to wildly varying performance results after minor
configuration changes.
In addition to aligning the start of descriptor array, also force the
size of individual descriptors to be of a common cache line size (64
bytes). That happens to already be the case on 64bit platforms, but
this way we can change the struct BufferDesc more easily.
As the alignment primarily matters in highly concurrent workloads
which probably all are 64bit these days, and the space wastage of
element alignment would be a bit more noticeable on 32bit systems, we
don't force the stride to be cacheline sized on 32bit platforms for
now. If somebody does actual performance testing, we can reevaluate
that decision by changing the definition of BUFFERDESC_PADDED_SIZE.
Discussion: 20140202151319.GD32123@awork2.anarazel.de
Per discussion with Bruce Momjan, Tom Lane, Robert Haas, and Peter
Geoghegan.
2015-01-29 17:49:03 +01:00
|
|
|
BufferDesc *bufHdr = GetLocalBufferDescriptor(i);
|
2005-11-17 18:42:02 +01:00
|
|
|
LocalBufferLookupEnt *hresult;
|
Allow Pin/UnpinBuffer to operate in a lockfree manner.
Pinning/Unpinning a buffer is a very frequent operation; especially in
read-mostly cache resident workloads. Benchmarking shows that in various
scenarios the spinlock protecting a buffer header's state becomes a
significant bottleneck. The problem can be reproduced with pgbench -S on
larger machines, but can be considerably worse for queries which touch
the same buffers over and over at a high frequency (e.g. nested loops
over a small inner table).
To allow atomic operations to be used, cram BufferDesc's flags,
usage_count, buf_hdr_lock, refcount into a single 32bit atomic variable;
that allows to manipulate them together using 32bit compare-and-swap
operations. This requires reducing MAX_BACKENDS to 2^18-1 (which could
be lifted by using a 64bit field, but it's not a realistic configuration
atm).
As not all operations can easily implemented in a lockfree manner,
implement the previous buf_hdr_lock via a flag bit in the atomic
variable. That way we can continue to lock the header in places where
it's needed, but can get away without acquiring it in the more frequent
hot-paths. There's some additional operations which can be done without
the lock, but aren't in this patch; but the most important places are
covered.
As bufmgr.c now essentially re-implements spinlocks, abstract the delay
logic from s_lock.c into something more generic. It now has already two
users, and more are coming up; there's a follupw patch for lwlock.c at
least.
This patch is based on a proof-of-concept written by me, which Alexander
Korotkov made into a fully working patch; the committed version is again
revised by me. Benchmarking and testing has, amongst others, been
provided by Dilip Kumar, Alexander Korotkov, Robert Haas.
On a large x86 system improvements for readonly pgbench, with a high
client count, of a factor of 8 have been observed.
Author: Alexander Korotkov and Andres Freund
Discussion: 2400449.GjM57CE0Yg@dinodell
2016-04-11 05:12:32 +02:00
|
|
|
uint32 buf_state;
|
2005-11-17 18:42:02 +01:00
|
|
|
|
Allow Pin/UnpinBuffer to operate in a lockfree manner.
Pinning/Unpinning a buffer is a very frequent operation; especially in
read-mostly cache resident workloads. Benchmarking shows that in various
scenarios the spinlock protecting a buffer header's state becomes a
significant bottleneck. The problem can be reproduced with pgbench -S on
larger machines, but can be considerably worse for queries which touch
the same buffers over and over at a high frequency (e.g. nested loops
over a small inner table).
To allow atomic operations to be used, cram BufferDesc's flags,
usage_count, buf_hdr_lock, refcount into a single 32bit atomic variable;
that allows to manipulate them together using 32bit compare-and-swap
operations. This requires reducing MAX_BACKENDS to 2^18-1 (which could
be lifted by using a 64bit field, but it's not a realistic configuration
atm).
As not all operations can easily implemented in a lockfree manner,
implement the previous buf_hdr_lock via a flag bit in the atomic
variable. That way we can continue to lock the header in places where
it's needed, but can get away without acquiring it in the more frequent
hot-paths. There's some additional operations which can be done without
the lock, but aren't in this patch; but the most important places are
covered.
As bufmgr.c now essentially re-implements spinlocks, abstract the delay
logic from s_lock.c into something more generic. It now has already two
users, and more are coming up; there's a follupw patch for lwlock.c at
least.
This patch is based on a proof-of-concept written by me, which Alexander
Korotkov made into a fully working patch; the committed version is again
revised by me. Benchmarking and testing has, amongst others, been
provided by Dilip Kumar, Alexander Korotkov, Robert Haas.
On a large x86 system improvements for readonly pgbench, with a high
client count, of a factor of 8 have been observed.
Author: Alexander Korotkov and Andres Freund
Discussion: 2400449.GjM57CE0Yg@dinodell
2016-04-11 05:12:32 +02:00
|
|
|
buf_state = pg_atomic_read_u32(&bufHdr->state);
|
|
|
|
|
|
|
|
if ((buf_state & BM_TAG_VALID) &&
|
2005-11-17 18:42:02 +01:00
|
|
|
RelFileNodeEquals(bufHdr->tag.rnode, rnode) &&
|
2008-08-11 13:05:11 +02:00
|
|
|
bufHdr->tag.forkNum == forkNum &&
|
2005-11-17 18:42:02 +01:00
|
|
|
bufHdr->tag.blockNum >= firstDelBlock)
|
|
|
|
{
|
|
|
|
if (LocalRefCount[i] != 0)
|
2008-11-11 14:19:16 +01:00
|
|
|
elog(ERROR, "block %u of %s is still referenced (local %u)",
|
2005-11-17 18:42:02 +01:00
|
|
|
bufHdr->tag.blockNum,
|
2010-08-13 22:10:54 +02:00
|
|
|
relpathbackend(bufHdr->tag.rnode, MyBackendId,
|
2011-04-10 17:42:00 +02:00
|
|
|
bufHdr->tag.forkNum),
|
2005-11-17 18:42:02 +01:00
|
|
|
LocalRefCount[i]);
|
|
|
|
/* Remove entry from hashtable */
|
|
|
|
hresult = (LocalBufferLookupEnt *)
|
|
|
|
hash_search(LocalBufHash, (void *) &bufHdr->tag,
|
|
|
|
HASH_REMOVE, NULL);
|
2005-11-22 19:17:34 +01:00
|
|
|
if (!hresult) /* shouldn't happen */
|
2005-11-17 18:42:02 +01:00
|
|
|
elog(ERROR, "local buffer hash table corrupted");
|
|
|
|
/* Mark buffer invalid */
|
|
|
|
CLEAR_BUFFERTAG(bufHdr->tag);
|
Allow Pin/UnpinBuffer to operate in a lockfree manner.
Pinning/Unpinning a buffer is a very frequent operation; especially in
read-mostly cache resident workloads. Benchmarking shows that in various
scenarios the spinlock protecting a buffer header's state becomes a
significant bottleneck. The problem can be reproduced with pgbench -S on
larger machines, but can be considerably worse for queries which touch
the same buffers over and over at a high frequency (e.g. nested loops
over a small inner table).
To allow atomic operations to be used, cram BufferDesc's flags,
usage_count, buf_hdr_lock, refcount into a single 32bit atomic variable;
that allows to manipulate them together using 32bit compare-and-swap
operations. This requires reducing MAX_BACKENDS to 2^18-1 (which could
be lifted by using a 64bit field, but it's not a realistic configuration
atm).
As not all operations can easily implemented in a lockfree manner,
implement the previous buf_hdr_lock via a flag bit in the atomic
variable. That way we can continue to lock the header in places where
it's needed, but can get away without acquiring it in the more frequent
hot-paths. There's some additional operations which can be done without
the lock, but aren't in this patch; but the most important places are
covered.
As bufmgr.c now essentially re-implements spinlocks, abstract the delay
logic from s_lock.c into something more generic. It now has already two
users, and more are coming up; there's a follupw patch for lwlock.c at
least.
This patch is based on a proof-of-concept written by me, which Alexander
Korotkov made into a fully working patch; the committed version is again
revised by me. Benchmarking and testing has, amongst others, been
provided by Dilip Kumar, Alexander Korotkov, Robert Haas.
On a large x86 system improvements for readonly pgbench, with a high
client count, of a factor of 8 have been observed.
Author: Alexander Korotkov and Andres Freund
Discussion: 2400449.GjM57CE0Yg@dinodell
2016-04-11 05:12:32 +02:00
|
|
|
buf_state &= ~BUF_FLAG_MASK;
|
|
|
|
buf_state &= ~BUF_USAGECOUNT_MASK;
|
Fix fallback implementation of pg_atomic_write_u32().
I somehow had assumed that in the spinlock (in turn possibly using
semaphores) based fallback atomics implementation 32 bit writes could be
done without a lock. As far as the write goes that's correct, since
postgres supports only platforms with single-copy atomicity for aligned
32bit writes. But writing without holding the spinlock breaks
read-modify-write operations like pg_atomic_compare_exchange_u32(),
since they'll potentially "miss" a concurrent write, which can't happen
in actual hardware implementations.
In 9.6+ when using the fallback atomics implementation this could lead
to buffer header locks not being properly marked as released, and
potentially some related state corruption. I don't see a related danger
in 9.5 (earliest release with the API), because pg_atomic_write_u32()
wasn't used in a concurrent manner there.
The state variable of local buffers, before this change, were
manipulated using pg_atomic_write_u32(), to avoid unnecessary
synchronization overhead. As that'd not be the case anymore, introduce
and use pg_atomic_unlocked_write_u32(), which does not correctly
interact with RMW operations.
This bug only caused issues when postgres is compiled on platforms
without atomics support (i.e. no common new platform), or when compiled
with --disable-atomics, which explains why this wasn't noticed in
testing.
Reported-By: Tom Lane
Discussion: <14947.1475690465@sss.pgh.pa.us>
Backpatch: 9.5-, where the atomic operations API was introduced.
2016-10-08 01:55:15 +02:00
|
|
|
pg_atomic_unlocked_write_u32(&bufHdr->state, buf_state);
|
2005-11-17 18:42:02 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-06-07 23:42:27 +02:00
|
|
|
/*
|
|
|
|
* DropRelFileNodeAllLocalBuffers
|
|
|
|
* This function removes from the buffer pool all pages of all forks
|
|
|
|
* of the specified relation.
|
|
|
|
*
|
|
|
|
* See DropRelFileNodeAllBuffers in bufmgr.c for more notes.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
DropRelFileNodeAllLocalBuffers(RelFileNode rnode)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < NLocBuffer; i++)
|
|
|
|
{
|
Align buffer descriptors to cache line boundaries.
Benchmarks has shown that aligning the buffer descriptor array to
cache lines is important for scalability; especially on bigger,
multi-socket, machines.
Currently the array sometimes already happens to be aligned by
happenstance, depending how large previous shared memory allocations
were. That can lead to wildly varying performance results after minor
configuration changes.
In addition to aligning the start of descriptor array, also force the
size of individual descriptors to be of a common cache line size (64
bytes). That happens to already be the case on 64bit platforms, but
this way we can change the struct BufferDesc more easily.
As the alignment primarily matters in highly concurrent workloads
which probably all are 64bit these days, and the space wastage of
element alignment would be a bit more noticeable on 32bit systems, we
don't force the stride to be cacheline sized on 32bit platforms for
now. If somebody does actual performance testing, we can reevaluate
that decision by changing the definition of BUFFERDESC_PADDED_SIZE.
Discussion: 20140202151319.GD32123@awork2.anarazel.de
Per discussion with Bruce Momjan, Tom Lane, Robert Haas, and Peter
Geoghegan.
2015-01-29 17:49:03 +01:00
|
|
|
BufferDesc *bufHdr = GetLocalBufferDescriptor(i);
|
2012-06-07 23:42:27 +02:00
|
|
|
LocalBufferLookupEnt *hresult;
|
Allow Pin/UnpinBuffer to operate in a lockfree manner.
Pinning/Unpinning a buffer is a very frequent operation; especially in
read-mostly cache resident workloads. Benchmarking shows that in various
scenarios the spinlock protecting a buffer header's state becomes a
significant bottleneck. The problem can be reproduced with pgbench -S on
larger machines, but can be considerably worse for queries which touch
the same buffers over and over at a high frequency (e.g. nested loops
over a small inner table).
To allow atomic operations to be used, cram BufferDesc's flags,
usage_count, buf_hdr_lock, refcount into a single 32bit atomic variable;
that allows to manipulate them together using 32bit compare-and-swap
operations. This requires reducing MAX_BACKENDS to 2^18-1 (which could
be lifted by using a 64bit field, but it's not a realistic configuration
atm).
As not all operations can easily implemented in a lockfree manner,
implement the previous buf_hdr_lock via a flag bit in the atomic
variable. That way we can continue to lock the header in places where
it's needed, but can get away without acquiring it in the more frequent
hot-paths. There's some additional operations which can be done without
the lock, but aren't in this patch; but the most important places are
covered.
As bufmgr.c now essentially re-implements spinlocks, abstract the delay
logic from s_lock.c into something more generic. It now has already two
users, and more are coming up; there's a follupw patch for lwlock.c at
least.
This patch is based on a proof-of-concept written by me, which Alexander
Korotkov made into a fully working patch; the committed version is again
revised by me. Benchmarking and testing has, amongst others, been
provided by Dilip Kumar, Alexander Korotkov, Robert Haas.
On a large x86 system improvements for readonly pgbench, with a high
client count, of a factor of 8 have been observed.
Author: Alexander Korotkov and Andres Freund
Discussion: 2400449.GjM57CE0Yg@dinodell
2016-04-11 05:12:32 +02:00
|
|
|
uint32 buf_state;
|
|
|
|
|
|
|
|
buf_state = pg_atomic_read_u32(&bufHdr->state);
|
2012-06-07 23:42:27 +02:00
|
|
|
|
Allow Pin/UnpinBuffer to operate in a lockfree manner.
Pinning/Unpinning a buffer is a very frequent operation; especially in
read-mostly cache resident workloads. Benchmarking shows that in various
scenarios the spinlock protecting a buffer header's state becomes a
significant bottleneck. The problem can be reproduced with pgbench -S on
larger machines, but can be considerably worse for queries which touch
the same buffers over and over at a high frequency (e.g. nested loops
over a small inner table).
To allow atomic operations to be used, cram BufferDesc's flags,
usage_count, buf_hdr_lock, refcount into a single 32bit atomic variable;
that allows to manipulate them together using 32bit compare-and-swap
operations. This requires reducing MAX_BACKENDS to 2^18-1 (which could
be lifted by using a 64bit field, but it's not a realistic configuration
atm).
As not all operations can easily implemented in a lockfree manner,
implement the previous buf_hdr_lock via a flag bit in the atomic
variable. That way we can continue to lock the header in places where
it's needed, but can get away without acquiring it in the more frequent
hot-paths. There's some additional operations which can be done without
the lock, but aren't in this patch; but the most important places are
covered.
As bufmgr.c now essentially re-implements spinlocks, abstract the delay
logic from s_lock.c into something more generic. It now has already two
users, and more are coming up; there's a follupw patch for lwlock.c at
least.
This patch is based on a proof-of-concept written by me, which Alexander
Korotkov made into a fully working patch; the committed version is again
revised by me. Benchmarking and testing has, amongst others, been
provided by Dilip Kumar, Alexander Korotkov, Robert Haas.
On a large x86 system improvements for readonly pgbench, with a high
client count, of a factor of 8 have been observed.
Author: Alexander Korotkov and Andres Freund
Discussion: 2400449.GjM57CE0Yg@dinodell
2016-04-11 05:12:32 +02:00
|
|
|
if ((buf_state & BM_TAG_VALID) &&
|
2012-06-07 23:42:27 +02:00
|
|
|
RelFileNodeEquals(bufHdr->tag.rnode, rnode))
|
|
|
|
{
|
|
|
|
if (LocalRefCount[i] != 0)
|
|
|
|
elog(ERROR, "block %u of %s is still referenced (local %u)",
|
|
|
|
bufHdr->tag.blockNum,
|
|
|
|
relpathbackend(bufHdr->tag.rnode, MyBackendId,
|
|
|
|
bufHdr->tag.forkNum),
|
|
|
|
LocalRefCount[i]);
|
|
|
|
/* Remove entry from hashtable */
|
|
|
|
hresult = (LocalBufferLookupEnt *)
|
|
|
|
hash_search(LocalBufHash, (void *) &bufHdr->tag,
|
|
|
|
HASH_REMOVE, NULL);
|
|
|
|
if (!hresult) /* shouldn't happen */
|
|
|
|
elog(ERROR, "local buffer hash table corrupted");
|
|
|
|
/* Mark buffer invalid */
|
|
|
|
CLEAR_BUFFERTAG(bufHdr->tag);
|
Allow Pin/UnpinBuffer to operate in a lockfree manner.
Pinning/Unpinning a buffer is a very frequent operation; especially in
read-mostly cache resident workloads. Benchmarking shows that in various
scenarios the spinlock protecting a buffer header's state becomes a
significant bottleneck. The problem can be reproduced with pgbench -S on
larger machines, but can be considerably worse for queries which touch
the same buffers over and over at a high frequency (e.g. nested loops
over a small inner table).
To allow atomic operations to be used, cram BufferDesc's flags,
usage_count, buf_hdr_lock, refcount into a single 32bit atomic variable;
that allows to manipulate them together using 32bit compare-and-swap
operations. This requires reducing MAX_BACKENDS to 2^18-1 (which could
be lifted by using a 64bit field, but it's not a realistic configuration
atm).
As not all operations can easily implemented in a lockfree manner,
implement the previous buf_hdr_lock via a flag bit in the atomic
variable. That way we can continue to lock the header in places where
it's needed, but can get away without acquiring it in the more frequent
hot-paths. There's some additional operations which can be done without
the lock, but aren't in this patch; but the most important places are
covered.
As bufmgr.c now essentially re-implements spinlocks, abstract the delay
logic from s_lock.c into something more generic. It now has already two
users, and more are coming up; there's a follupw patch for lwlock.c at
least.
This patch is based on a proof-of-concept written by me, which Alexander
Korotkov made into a fully working patch; the committed version is again
revised by me. Benchmarking and testing has, amongst others, been
provided by Dilip Kumar, Alexander Korotkov, Robert Haas.
On a large x86 system improvements for readonly pgbench, with a high
client count, of a factor of 8 have been observed.
Author: Alexander Korotkov and Andres Freund
Discussion: 2400449.GjM57CE0Yg@dinodell
2016-04-11 05:12:32 +02:00
|
|
|
buf_state &= ~BUF_FLAG_MASK;
|
|
|
|
buf_state &= ~BUF_USAGECOUNT_MASK;
|
Fix fallback implementation of pg_atomic_write_u32().
I somehow had assumed that in the spinlock (in turn possibly using
semaphores) based fallback atomics implementation 32 bit writes could be
done without a lock. As far as the write goes that's correct, since
postgres supports only platforms with single-copy atomicity for aligned
32bit writes. But writing without holding the spinlock breaks
read-modify-write operations like pg_atomic_compare_exchange_u32(),
since they'll potentially "miss" a concurrent write, which can't happen
in actual hardware implementations.
In 9.6+ when using the fallback atomics implementation this could lead
to buffer header locks not being properly marked as released, and
potentially some related state corruption. I don't see a related danger
in 9.5 (earliest release with the API), because pg_atomic_write_u32()
wasn't used in a concurrent manner there.
The state variable of local buffers, before this change, were
manipulated using pg_atomic_write_u32(), to avoid unnecessary
synchronization overhead. As that'd not be the case anymore, introduce
and use pg_atomic_unlocked_write_u32(), which does not correctly
interact with RMW operations.
This bug only caused issues when postgres is compiled on platforms
without atomics support (i.e. no common new platform), or when compiled
with --disable-atomics, which explains why this wasn't noticed in
testing.
Reported-By: Tom Lane
Discussion: <14947.1475690465@sss.pgh.pa.us>
Backpatch: 9.5-, where the atomic operations API was introduced.
2016-10-08 01:55:15 +02:00
|
|
|
pg_atomic_unlocked_write_u32(&bufHdr->state, buf_state);
|
2012-06-07 23:42:27 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*
|
2005-03-20 00:27:11 +01:00
|
|
|
* InitLocalBuffers -
|
1997-09-07 07:04:48 +02:00
|
|
|
* init the local buffer cache. Since most queries (esp. multi-user ones)
|
2000-11-30 02:39:08 +01:00
|
|
|
* don't involve local buffers, we delay allocating actual memory for the
|
2002-08-06 04:36:35 +02:00
|
|
|
* buffers until we need them; just make the buffer headers here.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2005-03-20 00:27:11 +01:00
|
|
|
static void
|
|
|
|
InitLocalBuffers(void)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2005-03-20 00:27:11 +01:00
|
|
|
int nbufs = num_temp_buffers;
|
2005-03-19 18:39:43 +01:00
|
|
|
HASHCTL info;
|
1997-09-08 04:41:22 +02:00
|
|
|
int i;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
Improve the situation for parallel query versus temp relations.
Transmit the leader's temp-namespace state to workers. This is important
because without it, the workers do not really have the same search path
as the leader. For example, there is no good reason (and no extant code
either) to prevent a worker from executing a temp function that the
leader created previously; but as things stood it would fail to find the
temp function, and then either fail or execute the wrong function entirely.
We still prohibit a worker from creating a temp namespace on its own.
In effect, a worker can only see the session's temp namespace if the leader
had created it before starting the worker, which seems like the right
semantics.
Also, transmit the leader's BackendId to workers, and arrange for workers
to use that when determining the physical file path of a temp relation
belonging to their session. While the original intent was to prevent such
accesses entirely, there were a number of holes in that, notably in places
like dbsize.c which assume they can safely access temp rels of other
sessions anyway. We might as well get this right, as a small down payment
on someday allowing workers to access the leader's temp tables. (With
this change, directly using "MyBackendId" as a relation or buffer backend
ID is deprecated; you should use BackendIdForTempRelations() instead.
I left a couple of such uses alone though, as they're not going to be
reachable in parallel workers until we do something about localbuf.c.)
Move the thou-shalt-not-access-thy-leader's-temp-tables prohibition down
into localbuf.c, which is where it actually matters, instead of having it
in relation_open(). This amounts to recognizing that access to temp
tables' catalog entries is perfectly safe in a worker, it's only the data
in local buffers that is problematic.
Having done all that, we can get rid of the test in has_parallel_hazard()
that says that use of a temp table's rowtype is unsafe in parallel workers.
That test was unduly expensive, and if we really did need such a
prohibition, that was not even close to being a bulletproof guard for it.
(For example, any user-defined function executed in a parallel worker
might have attempted such access.)
2016-06-10 02:16:11 +02:00
|
|
|
/*
|
|
|
|
* Parallel workers can't access data in temporary tables, because they
|
|
|
|
* have no visibility into the local buffers of their leader. This is a
|
|
|
|
* convenient, low-cost place to provide a backstop check for that. Note
|
|
|
|
* that we don't wish to prevent a parallel worker from accessing catalog
|
|
|
|
* metadata about a temp table, so checks at higher levels would be
|
|
|
|
* inappropriate.
|
|
|
|
*/
|
|
|
|
if (IsParallelWorker())
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TRANSACTION_STATE),
|
|
|
|
errmsg("cannot access temporary tables during a parallel operation")));
|
|
|
|
|
2005-03-19 18:39:43 +01:00
|
|
|
/* Allocate and zero buffer headers and auxiliary arrays */
|
2005-08-21 01:26:37 +02:00
|
|
|
LocalBufferDescriptors = (BufferDesc *) calloc(nbufs, sizeof(BufferDesc));
|
|
|
|
LocalBufferBlockPointers = (Block *) calloc(nbufs, sizeof(Block));
|
|
|
|
LocalRefCount = (int32 *) calloc(nbufs, sizeof(int32));
|
|
|
|
if (!LocalBufferDescriptors || !LocalBufferBlockPointers || !LocalRefCount)
|
|
|
|
ereport(FATAL,
|
|
|
|
(errcode(ERRCODE_OUT_OF_MEMORY),
|
|
|
|
errmsg("out of memory")));
|
2005-03-19 18:39:43 +01:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
nextFreeLocalBuf = 0;
|
|
|
|
|
2005-03-19 18:39:43 +01:00
|
|
|
/* initialize fields that need to start off nonzero */
|
|
|
|
for (i = 0; i < nbufs; i++)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
Align buffer descriptors to cache line boundaries.
Benchmarks has shown that aligning the buffer descriptor array to
cache lines is important for scalability; especially on bigger,
multi-socket, machines.
Currently the array sometimes already happens to be aligned by
happenstance, depending how large previous shared memory allocations
were. That can lead to wildly varying performance results after minor
configuration changes.
In addition to aligning the start of descriptor array, also force the
size of individual descriptors to be of a common cache line size (64
bytes). That happens to already be the case on 64bit platforms, but
this way we can change the struct BufferDesc more easily.
As the alignment primarily matters in highly concurrent workloads
which probably all are 64bit these days, and the space wastage of
element alignment would be a bit more noticeable on 32bit systems, we
don't force the stride to be cacheline sized on 32bit platforms for
now. If somebody does actual performance testing, we can reevaluate
that decision by changing the definition of BUFFERDESC_PADDED_SIZE.
Discussion: 20140202151319.GD32123@awork2.anarazel.de
Per discussion with Bruce Momjan, Tom Lane, Robert Haas, and Peter
Geoghegan.
2015-01-29 17:49:03 +01:00
|
|
|
BufferDesc *buf = GetLocalBufferDescriptor(i);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* negative to indicate local buffer. This is tricky: shared buffers
|
|
|
|
* start with 0. We have to start with -2. (Note that the routine
|
|
|
|
* BufferDescriptorGetBuffer adds 1 to buf_id so our first buffer id
|
|
|
|
* is -1.)
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
|
|
|
buf->buf_id = -i - 2;
|
2016-04-14 00:28:29 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Intentionally do not initialize the buffer's atomic variable
|
|
|
|
* (besides zeroing the underlying memory above). That way we get
|
|
|
|
* errors on platforms without atomics, if somebody (re-)introduces
|
|
|
|
* atomic operations for local buffers.
|
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
2005-03-19 18:39:43 +01:00
|
|
|
|
2005-03-20 00:27:11 +01:00
|
|
|
/* Create the lookup hash table */
|
|
|
|
MemSet(&info, 0, sizeof(info));
|
|
|
|
info.keysize = sizeof(BufferTag);
|
|
|
|
info.entrysize = sizeof(LocalBufferLookupEnt);
|
|
|
|
|
|
|
|
LocalBufHash = hash_create("Local Buffer Lookup Table",
|
|
|
|
nbufs,
|
|
|
|
&info,
|
Improve hash_create's API for selecting simple-binary-key hash functions.
Previously, if you wanted anything besides C-string hash keys, you had to
specify a custom hashing function to hash_create(). Nearly all such
callers were specifying tag_hash or oid_hash; which is tedious, and rather
error-prone, since a caller could easily miss the opportunity to optimize
by using hash_uint32 when appropriate. Replace this with a design whereby
callers using simple binary-data keys just specify HASH_BLOBS and don't
need to mess with specific support functions. hash_create() itself will
take care of optimizing when the key size is four bytes.
This nets out saving a few hundred bytes of code space, and offers
a measurable performance improvement in tidbitmap.c (which was not
exploiting the opportunity to use hash_uint32 for its 4-byte keys).
There might be some wins elsewhere too, I didn't analyze closely.
In future we could look into offering a similar optimized hashing function
for 8-byte keys. Under this design that could be done in a centralized
and machine-independent fashion, whereas getting it right for keys of
platform-dependent sizes would've been notationally painful before.
For the moment, the old way still works fine, so as not to break source
code compatibility for loadable modules. Eventually we might want to
remove tag_hash and friends from the exported API altogether, since there's
no real need for them to be explicitly referenced from outside dynahash.c.
Teodor Sigaev and Tom Lane
2014-12-18 19:36:29 +01:00
|
|
|
HASH_ELEM | HASH_BLOBS);
|
2005-03-20 00:27:11 +01:00
|
|
|
|
|
|
|
if (!LocalBufHash)
|
|
|
|
elog(ERROR, "could not initialize local buffer hash table");
|
|
|
|
|
2005-03-19 18:39:43 +01:00
|
|
|
/* Initialization done, mark buffers allocated */
|
|
|
|
NLocBuffer = nbufs;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2006-12-27 23:31:54 +01:00
|
|
|
/*
|
|
|
|
* GetLocalBufferStorage - allocate memory for a local buffer
|
|
|
|
*
|
|
|
|
* The idea of this function is to aggregate our requests for storage
|
|
|
|
* so that the memory manager doesn't see a whole lot of relatively small
|
|
|
|
* requests. Since we'll never give back a local buffer once it's created
|
|
|
|
* within a particular process, no point in burdening memmgr with separately
|
|
|
|
* managed chunks.
|
|
|
|
*/
|
|
|
|
static Block
|
|
|
|
GetLocalBufferStorage(void)
|
|
|
|
{
|
|
|
|
static char *cur_block = NULL;
|
|
|
|
static int next_buf_in_block = 0;
|
|
|
|
static int num_bufs_in_block = 0;
|
|
|
|
static int total_bufs_allocated = 0;
|
2010-08-19 18:16:20 +02:00
|
|
|
static MemoryContext LocalBufferContext = NULL;
|
2006-12-27 23:31:54 +01:00
|
|
|
|
|
|
|
char *this_buf;
|
|
|
|
|
|
|
|
Assert(total_bufs_allocated < NLocBuffer);
|
|
|
|
|
|
|
|
if (next_buf_in_block >= num_bufs_in_block)
|
|
|
|
{
|
|
|
|
/* Need to make a new request to memmgr */
|
2007-11-15 22:14:46 +01:00
|
|
|
int num_bufs;
|
2006-12-27 23:31:54 +01:00
|
|
|
|
2010-08-19 18:16:20 +02:00
|
|
|
/*
|
|
|
|
* We allocate local buffers in a context of their own, so that the
|
|
|
|
* space eaten for them is easily recognizable in MemoryContextStats
|
2014-05-06 18:12:18 +02:00
|
|
|
* output. Create the context on first use.
|
2010-08-19 18:16:20 +02:00
|
|
|
*/
|
|
|
|
if (LocalBufferContext == NULL)
|
|
|
|
LocalBufferContext =
|
|
|
|
AllocSetContextCreate(TopMemoryContext,
|
|
|
|
"LocalBufferContext",
|
Add macros to make AllocSetContextCreate() calls simpler and safer.
I found that half a dozen (nearly 5%) of our AllocSetContextCreate calls
had typos in the context-sizing parameters. While none of these led to
especially significant problems, they did create minor inefficiencies,
and it's now clear that expecting people to copy-and-paste those calls
accurately is not a great idea. Let's reduce the risk of future errors
by introducing single macros that encapsulate the common use-cases.
Three such macros are enough to cover all but two special-purpose contexts;
those two calls can be left as-is, I think.
While this patch doesn't in itself improve matters for third-party
extensions, it doesn't break anything for them either, and they can
gradually adopt the simplified notation over time.
In passing, change TopMemoryContext to use the default allocation
parameters. Formerly it could only be extended 8K at a time. That was
probably reasonable when this code was written; but nowadays we create
many more contexts than we did then, so that it's not unusual to have a
couple hundred K in TopMemoryContext, even without considering various
dubious code that sticks other things there. There seems no good reason
not to let it use growing blocks like most other contexts.
Back-patch to 9.6, mostly because that's still close enough to HEAD that
it's easy to do so, and keeping the branches in sync can be expected to
avoid some future back-patching pain. The bugs fixed by these changes
don't seem to be significant enough to justify fixing them further back.
Discussion: <21072.1472321324@sss.pgh.pa.us>
2016-08-27 23:50:38 +02:00
|
|
|
ALLOCSET_DEFAULT_SIZES);
|
2010-08-19 18:16:20 +02:00
|
|
|
|
2006-12-27 23:31:54 +01:00
|
|
|
/* Start with a 16-buffer request; subsequent ones double each time */
|
|
|
|
num_bufs = Max(num_bufs_in_block * 2, 16);
|
|
|
|
/* But not more than what we need for all remaining local bufs */
|
|
|
|
num_bufs = Min(num_bufs, NLocBuffer - total_bufs_allocated);
|
|
|
|
/* And don't overflow MaxAllocSize, either */
|
|
|
|
num_bufs = Min(num_bufs, MaxAllocSize / BLCKSZ);
|
|
|
|
|
2010-08-19 18:16:20 +02:00
|
|
|
cur_block = (char *) MemoryContextAlloc(LocalBufferContext,
|
2006-12-27 23:31:54 +01:00
|
|
|
num_bufs * BLCKSZ);
|
|
|
|
next_buf_in_block = 0;
|
|
|
|
num_bufs_in_block = num_bufs;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Allocate next buffer in current memory block */
|
|
|
|
this_buf = cur_block + next_buf_in_block * BLCKSZ;
|
|
|
|
next_buf_in_block++;
|
|
|
|
total_bufs_allocated++;
|
|
|
|
|
|
|
|
return (Block) this_buf;
|
|
|
|
}
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*
|
2014-06-20 11:06:42 +02:00
|
|
|
* CheckForLocalBufferLeaks - ensure this backend holds no local buffer pins
|
2000-11-30 20:03:26 +01:00
|
|
|
*
|
2014-06-20 11:06:42 +02:00
|
|
|
* This is just like CheckBufferLeaks(), but for local buffers.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2014-06-20 11:06:42 +02:00
|
|
|
static void
|
|
|
|
CheckForLocalBufferLeaks(void)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2004-10-16 20:57:26 +02:00
|
|
|
#ifdef USE_ASSERT_CHECKING
|
2014-06-20 11:06:42 +02:00
|
|
|
if (LocalRefCount)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2013-03-15 17:26:26 +01:00
|
|
|
int RefCountErrors = 0;
|
2005-08-08 21:44:22 +02:00
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < NLocBuffer; i++)
|
|
|
|
{
|
2013-03-15 17:26:26 +01:00
|
|
|
if (LocalRefCount[i] != 0)
|
|
|
|
{
|
2013-05-29 22:58:43 +02:00
|
|
|
Buffer b = -i - 1;
|
2013-03-15 17:26:26 +01:00
|
|
|
|
|
|
|
PrintBufferLeakWarning(b);
|
|
|
|
RefCountErrors++;
|
|
|
|
}
|
2005-08-08 21:44:22 +02:00
|
|
|
}
|
2013-03-15 17:26:26 +01:00
|
|
|
Assert(RefCountErrors == 0);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
2004-10-16 20:57:26 +02:00
|
|
|
#endif
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
2005-03-18 17:16:09 +01:00
|
|
|
|
2014-06-20 11:06:42 +02:00
|
|
|
/*
|
|
|
|
* AtEOXact_LocalBuffers - clean up at end of transaction.
|
|
|
|
*
|
|
|
|
* This is just like AtEOXact_Buffers, but for local buffers.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
AtEOXact_LocalBuffers(bool isCommit)
|
|
|
|
{
|
|
|
|
CheckForLocalBufferLeaks();
|
|
|
|
}
|
|
|
|
|
2005-03-18 17:16:09 +01:00
|
|
|
/*
|
|
|
|
* AtProcExit_LocalBuffers - ensure we have dropped pins during backend exit.
|
|
|
|
*
|
2014-06-20 11:06:42 +02:00
|
|
|
* This is just like AtProcExit_Buffers, but for local buffers.
|
2005-03-18 17:16:09 +01:00
|
|
|
*/
|
|
|
|
void
|
|
|
|
AtProcExit_LocalBuffers(void)
|
|
|
|
{
|
2014-06-20 11:06:42 +02:00
|
|
|
/*
|
|
|
|
* We shouldn't be holding any remaining pins; if we are, and assertions
|
|
|
|
* aren't enabled, we'll fail later in DropRelFileNodeBuffers while trying
|
|
|
|
* to drop the temp rels.
|
|
|
|
*/
|
|
|
|
CheckForLocalBufferLeaks();
|
2005-03-18 17:16:09 +01:00
|
|
|
}
|