Skip to content

Commit 4c6cfcc

Browse files
committed
Fix query-cancel handling in spgdoinsert().
Knowing that a buggy opclass could cause an infinite insertion loop, spgdoinsert() intended to allow its loop to be interrupted by query cancel. However, that never actually worked, because in iterations after the first, we'd be holding buffer lock(s) which would cause InterruptHoldoffCount to be positive, preventing servicing of the interrupt. To fix, check if an interrupt is pending, and if so fall out of the insertion loop and service the interrupt after we've released the buffers. If it was indeed a query cancel, that's the end of the matter. If it was a non-canceling interrupt reason, make use of the existing provision to retry the whole insertion. (This isn't as wasteful as it might seem, since any upper-level index tuples we already created should be usable in the next attempt.) While there's no known instance of such a bug in existing release branches, it still seems like a good idea to back-patch this to all supported branches, since the behavior is fairly nasty if a loop does happen --- not only is it uncancelable, but it will quickly consume memory to the point of an OOM failure. In any case, this code is certainly not working as intended. Per report from Dilip Kumar. Discussion: https://postgr.es/m/CAFiTN-uxP_soPhVG840tRMQTBmtA_f_Y8N51G7DKYYqDh7XN-A@mail.gmail.com
1 parent 5673289 commit 4c6cfcc

File tree

1 file changed

+45
-7
lines changed

1 file changed

+45
-7
lines changed

src/backend/access/spgist/spgdoinsert.c

+45-7
Original file line numberDiff line numberDiff line change
@@ -1858,13 +1858,14 @@ spgSplitNodeAction(Relation index, SpGistState *state,
18581858
* Insert one item into the index.
18591859
*
18601860
* Returns true on success, false if we failed to complete the insertion
1861-
* because of conflict with a concurrent insert. In the latter case,
1862-
* caller should re-call spgdoinsert() with the same args.
1861+
* (typically because of conflict with a concurrent insert). In the latter
1862+
* case, caller should re-call spgdoinsert() with the same args.
18631863
*/
18641864
bool
18651865
spgdoinsert(Relation index, SpGistState *state,
18661866
ItemPointer heapPtr, Datum datum, bool isnull)
18671867
{
1868+
bool result = true;
18681869
int level = 0;
18691870
Datum leafDatum;
18701871
int leafSize;
@@ -1924,16 +1925,33 @@ spgdoinsert(Relation index, SpGistState *state,
19241925
parent.offnum = InvalidOffsetNumber;
19251926
parent.node = -1;
19261927

1928+
/*
1929+
* Before entering the loop, try to clear any pending interrupt condition.
1930+
* If a query cancel is pending, we might as well accept it now not later;
1931+
* while if a non-canceling condition is pending, servicing it here avoids
1932+
* having to restart the insertion and redo all the work so far.
1933+
*/
1934+
CHECK_FOR_INTERRUPTS();
1935+
19271936
for (;;)
19281937
{
19291938
bool isNew = false;
19301939

19311940
/*
19321941
* Bail out if query cancel is pending. We must have this somewhere
19331942
* in the loop since a broken opclass could produce an infinite
1934-
* picksplit loop.
1943+
* picksplit loop. However, because we'll be holding buffer lock(s)
1944+
* after the first iteration, ProcessInterrupts() wouldn't be able to
1945+
* throw a cancel error here. Hence, if we see that an interrupt is
1946+
* pending, break out of the loop and deal with the situation below.
1947+
* Set result = false because we must restart the insertion if the
1948+
* interrupt isn't a query-cancel-or-die case.
19351949
*/
1936-
CHECK_FOR_INTERRUPTS();
1950+
if (INTERRUPTS_PENDING_CONDITION())
1951+
{
1952+
result = false;
1953+
break;
1954+
}
19371955

19381956
if (current.blkno == InvalidBlockNumber)
19391957
{
@@ -2052,10 +2070,14 @@ spgdoinsert(Relation index, SpGistState *state,
20522070
* spgAddNode and spgSplitTuple cases will loop back to here to
20532071
* complete the insertion operation. Just in case the choose
20542072
* function is broken and produces add or split requests
2055-
* repeatedly, check for query cancel.
2073+
* repeatedly, check for query cancel (see comments above).
20562074
*/
20572075
process_inner_tuple:
2058-
CHECK_FOR_INTERRUPTS();
2076+
if (INTERRUPTS_PENDING_CONDITION())
2077+
{
2078+
result = false;
2079+
break;
2080+
}
20592081

20602082
innerTuple = (SpGistInnerTuple) PageGetItem(current.page,
20612083
PageGetItemId(current.page, current.offnum));
@@ -2178,5 +2200,21 @@ spgdoinsert(Relation index, SpGistState *state,
21782200
UnlockReleaseBuffer(parent.buffer);
21792201
}
21802202

2181-
return true;
2203+
/*
2204+
* We do not support being called while some outer function is holding a
2205+
* buffer lock (or any other reason to postpone query cancels). If that
2206+
* were the case, telling the caller to retry would create an infinite
2207+
* loop.
2208+
*/
2209+
Assert(INTERRUPTS_CAN_BE_PROCESSED());
2210+
2211+
/*
2212+
* Finally, check for interrupts again. If there was a query cancel,
2213+
* ProcessInterrupts() will be able to throw the error here. If it was
2214+
* some other kind of interrupt that can just be cleared, return false to
2215+
* tell our caller to retry.
2216+
*/
2217+
CHECK_FOR_INTERRUPTS();
2218+
2219+
return result;
21822220
}

0 commit comments

Comments
 (0)