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

Commitf70648d

Browse files
committed
Update comments related to the crash-safety of the visibility map.
In hio.c, document how we avoid deadlock with respect to visibility mapbuffer locks. In visibilitymap.c, update the LOCKING section of thefile header comment.Both oversights noted by Heikki Linnakangas.
1 parenta9d845b commitf70648d

File tree

2 files changed

+17
-3
lines changed

2 files changed

+17
-3
lines changed

‎src/backend/access/heap/hio.c

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -178,6 +178,10 @@ GetVisibilityMapPins(Relation relation, Buffer buffer1, Buffer buffer2,
178178
*happen if space is freed in that page after heap_update finds there's not
179179
*enough there).In that case, the page will be pinned and locked only once.
180180
*
181+
*For the vmbuffer and vmbuffer_other arguments, we avoid deadlock by
182+
*locking them only after locking the corresponding heap page, and taking
183+
*no further lwlocks while they are locked.
184+
*
181185
*We normally use FSM to help us find free space. However,
182186
*if HEAP_INSERT_SKIP_FSM is specified, we just append a new empty page to
183187
*the end of the relation if the tuple won't fit on the current target page.

‎src/backend/access/heap/visibilitymap.c

Lines changed: 13 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -45,9 +45,19 @@
4545
*
4646
* In heapam.c, whenever a page is modified so that not all tuples on the
4747
* page are visible to everyone anymore, the corresponding bit in the
48-
* visibility map is cleared. The bit in the visibility map is cleared
49-
* after releasing the lock on the heap page, to avoid holding the lock
50-
* over possible I/O to read in the visibility map page.
48+
* visibility map is cleared. In order to be crash-safe, we need to do this
49+
* while still holding a lock on the heap page and in the same critical
50+
* section that logs the page modification. However, we don't want to hold
51+
* the buffer lock over any I/O that may be required to read in the visibility
52+
* map page. To avoid this, we examine the heap page before locking it;
53+
* if the page-level PD_ALL_VISIBLE bit is set, we pin the visibility map
54+
* bit. Then, we lock the buffer. But this creates a race condition: there
55+
* is a possibility that in the time it takes to lock the buffer, the
56+
* PD_ALL_VISIBLE bit gets set. If that happens, we have to unlock the
57+
* buffer, pin the visibility map page, and relock the buffer. This shouldn't
58+
* happen often, because only VACUUM currently sets visibility map bits,
59+
* and the race will only occur if VACUUM processes a given page at almost
60+
* exactly the same time that someone tries to further modify it.
5161
*
5262
* To set a bit, you need to hold a lock on the heap page. That prevents
5363
* the race condition where VACUUM sees that all tuples on the page are

0 commit comments

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