1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Index Locking Considerations</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REV="MADE"
HREF="mailto:pgsql-docs@postgresql.org"><LINK
REL="HOME"
TITLE="PostgreSQL 9.3.13 Documentation"
HREF="index.html"><LINK
REL="UP"
TITLE="Index Access Method Interface Definition"
HREF="indexam.html"><LINK
REL="PREVIOUS"
TITLE="Index Scanning"
HREF="index-scanning.html"><LINK
REL="NEXT"
TITLE="Index Uniqueness Checks"
HREF="index-unique-checks.html"><LINK
REL="STYLESHEET"
TYPE="text/css"
HREF="stylesheet.css"><META
HTTP-EQUIV="Content-Type"
CONTENT="text/html; charset=ISO-8859-1"><META
NAME="creation"
CONTENT="2016-05-09T21:13:26"></HEAD
><BODY
CLASS="SECT1"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="5"
ALIGN="center"
VALIGN="bottom"
><A
HREF="index.html"
>PostgreSQL 9.3.13 Documentation</A
></TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
TITLE="Index Scanning"
HREF="index-scanning.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="indexam.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="60%"
ALIGN="center"
VALIGN="bottom"
>Chapter 54. Index Access Method Interface Definition</TD
><TD
WIDTH="20%"
ALIGN="right"
VALIGN="top"
><A
TITLE="Index Uniqueness Checks"
HREF="index-unique-checks.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="INDEX-LOCKING"
>54.4. Index Locking Considerations</A
></H1
><P
> Index access methods must handle concurrent updates
of the index by multiple processes.
The core <SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
> system obtains
<TT
CLASS="LITERAL"
>AccessShareLock</TT
> on the index during an index scan, and
<TT
CLASS="LITERAL"
>RowExclusiveLock</TT
> when updating the index (including plain
<TT
CLASS="COMMAND"
>VACUUM</TT
>). Since these lock types do not conflict, the access
method is responsible for handling any fine-grained locking it might need.
An exclusive lock on the index as a whole will be taken only during index
creation, destruction, or <TT
CLASS="COMMAND"
>REINDEX</TT
>.
</P
><P
> Building an index type that supports concurrent updates usually requires
extensive and subtle analysis of the required behavior. For the b-tree
and hash index types, you can read about the design decisions involved in
<TT
CLASS="FILENAME"
>src/backend/access/nbtree/README</TT
> and
<TT
CLASS="FILENAME"
>src/backend/access/hash/README</TT
>.
</P
><P
> Aside from the index's own internal consistency requirements, concurrent
updates create issues about consistency between the parent table (the
<I
CLASS="FIRSTTERM"
>heap</I
>) and the index. Because
<SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
> separates accesses
and updates of the heap from those of the index, there are windows in
which the index might be inconsistent with the heap. We handle this problem
with the following rules:
<P
></P
></P><UL
><LI
><P
> A new heap entry is made before making its index entries. (Therefore
a concurrent index scan is likely to fail to see the heap entry.
This is okay because the index reader would be uninterested in an
uncommitted row anyway. But see <A
HREF="index-unique-checks.html"
>Section 54.5</A
>.)
</P
></LI
><LI
><P
> When a heap entry is to be deleted (by <TT
CLASS="COMMAND"
>VACUUM</TT
>), all its
index entries must be removed first.
</P
></LI
><LI
><P
> An index scan must maintain a pin
on the index page holding the item last returned by
<CODE
CLASS="FUNCTION"
>amgettuple</CODE
>, and <CODE
CLASS="FUNCTION"
>ambulkdelete</CODE
> cannot delete
entries from pages that are pinned by other backends. The need
for this rule is explained below.
</P
></LI
></UL
><P>
Without the third rule, it is possible for an index reader to
see an index entry just before it is removed by <TT
CLASS="COMMAND"
>VACUUM</TT
>, and
then to arrive at the corresponding heap entry after that was removed by
<TT
CLASS="COMMAND"
>VACUUM</TT
>.
This creates no serious problems if that item
number is still unused when the reader reaches it, since an empty
item slot will be ignored by <CODE
CLASS="FUNCTION"
>heap_fetch()</CODE
>. But what if a
third backend has already re-used the item slot for something else?
When using an MVCC-compliant snapshot, there is no problem because
the new occupant of the slot is certain to be too new to pass the
snapshot test. However, with a non-MVCC-compliant snapshot (such as
<TT
CLASS="LITERAL"
>SnapshotNow</TT
>), it would be possible to accept and return
a row that does not in fact match the scan keys. We could defend
against this scenario by requiring the scan keys to be rechecked
against the heap row in all cases, but that is too expensive. Instead,
we use a pin on an index page as a proxy to indicate that the reader
might still be <SPAN
CLASS="QUOTE"
>"in flight"</SPAN
> from the index entry to the matching
heap entry. Making <CODE
CLASS="FUNCTION"
>ambulkdelete</CODE
> block on such a pin ensures
that <TT
CLASS="COMMAND"
>VACUUM</TT
> cannot delete the heap entry before the reader
is done with it. This solution costs little in run time, and adds blocking
overhead only in the rare cases where there actually is a conflict.
</P
><P
> This solution requires that index scans be <SPAN
CLASS="QUOTE"
>"synchronous"</SPAN
>: we have
to fetch each heap tuple immediately after scanning the corresponding index
entry. This is expensive for a number of reasons. An
<SPAN
CLASS="QUOTE"
>"asynchronous"</SPAN
> scan in which we collect many TIDs from the index,
and only visit the heap tuples sometime later, requires much less index
locking overhead and can allow a more efficient heap access pattern.
Per the above analysis, we must use the synchronous approach for
non-MVCC-compliant snapshots, but an asynchronous scan is workable
for a query using an MVCC snapshot.
</P
><P
> In an <CODE
CLASS="FUNCTION"
>amgetbitmap</CODE
> index scan, the access method does not
keep an index pin on any of the returned tuples. Therefore
it is only safe to use such scans with MVCC-compliant snapshots.
</P
><P
> When the <TT
CLASS="STRUCTFIELD"
>ampredlocks</TT
> flag is not set, any scan using that
index access method within a serializable transaction will acquire a
nonblocking predicate lock on the full index. This will generate a
read-write conflict with the insert of any tuple into that index by a
concurrent serializable transaction. If certain patterns of read-write
conflicts are detected among a set of concurrent serializable
transactions, one of those transactions may be canceled to protect data
integrity. When the flag is set, it indicates that the index access
method implements finer-grained predicate locking, which will tend to
reduce the frequency of such transaction cancellations.
</P
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="index-scanning.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="index-unique-checks.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Index Scanning</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="indexam.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Index Uniqueness Checks</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
|