Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit6e65454

Browse files
committed
Don't bother to lock bufmgr partitions in pg_buffercache.
That makes the view a lot less disruptive to use on a production system.Without the locks, you don't get a consistent snapshot across all buffers,but that's OK. It wasn't a very useful guarantee in practice.Ivan Kartyshov, reviewed by Tomas Vondra and Robert Haas.Discusssion: <f9d6cab2-73a7-7a84-55a8-07dcb8516ae5@postgrespro.ru>
1 parent6ad8ac6 commit6e65454

File tree

1 file changed

+4
-19
lines changed

1 file changed

+4
-19
lines changed

‎contrib/pg_buffercache/pg_buffercache_pages.c

Lines changed: 4 additions & 19 deletions
Original file line numberDiff line numberDiff line change
@@ -135,18 +135,13 @@ pg_buffercache_pages(PG_FUNCTION_ARGS)
135135
/* Return to original context when allocating transient memory */
136136
MemoryContextSwitchTo(oldcontext);
137137

138-
/*
139-
* To get a consistent picture of the buffer state, we must lock all
140-
* partitions of the buffer map. Needless to say, this is horrible
141-
* for concurrency. Must grab locks in increasing order to avoid
142-
* possible deadlocks.
143-
*/
144-
for (i=0;i<NUM_BUFFER_PARTITIONS;i++)
145-
LWLockAcquire(BufMappingPartitionLockByIndex(i),LW_SHARED);
146-
147138
/*
148139
* Scan through all the buffers, saving the relevant fields in the
149140
* fctx->record structure.
141+
*
142+
* We don't hold the partition locks, so we don't get a consistent
143+
* snapshot across all buffers, but we do grab the buffer header
144+
* locks, so the information of each buffer is self-consistent.
150145
*/
151146
for (i=0;i<NBuffers;i++)
152147
{
@@ -179,16 +174,6 @@ pg_buffercache_pages(PG_FUNCTION_ARGS)
179174

180175
UnlockBufHdr(bufHdr,buf_state);
181176
}
182-
183-
/*
184-
* And release locks. We do this in reverse order for two reasons:
185-
* (1) Anyone else who needs more than one of the locks will be trying
186-
* to lock them in increasing order; we don't want to release the
187-
* other process until it can get all the locks it needs. (2) This
188-
* avoids O(N^2) behavior inside LWLockRelease.
189-
*/
190-
for (i=NUM_BUFFER_PARTITIONS;--i >=0;)
191-
LWLockRelease(BufMappingPartitionLockByIndex(i));
192177
}
193178

194179
funcctx=SRF_PERCALL_SETUP();

0 commit comments

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