Fix possible cache invalidation failure in ReceiveSharedInvalidMessages.
authorTom Lane <[email protected]>
Mon, 5 May 2014 18:43:55 +0000 (14:43 -0400)
committerTom Lane <[email protected]>
Mon, 5 May 2014 18:43:55 +0000 (14:43 -0400)
Commit fad153ec45299bd4d4f29dec8d9e04e2f1c08148 modified sinval.c to reduce
the number of calls into sinvaladt.c (which require taking a shared lock)
by keeping a local buffer of collected-but-not-yet-processed messages.
However, if processing of the last message in a batch resulted in a
recursive call to ReceiveSharedInvalidMessages, we could overwrite that
message with a new one while the outer invalidation function was still
working on it.  This would be likely to lead to invalidation of the wrong
cache entry, allowing subsequent processing to use stale cache data.
The fix is just to make a local copy of each message while we're processing
it.

Spotted by Andres Freund.  Back-patch to 8.4 where the bug was introduced.

src/backend/storage/ipc/sinval.c

index 9028ede2eb0e4071e93bb7411971bbe7ce6e00f3..4b3d42348f13717b6abebe3b4627cbc921de2e1a 100644 (file)
@@ -88,9 +88,9 @@ ReceiveSharedInvalidMessages(
    /* Deal with any messages still pending from an outer recursion */
    while (nextmsg < nummsgs)
    {
-       SharedInvalidationMessage *msg = &messages[nextmsg++];
+       SharedInvalidationMessage msg = messages[nextmsg++];
 
-       invalFunction(msg);
+       invalFunction(&msg);
    }
 
    do
@@ -116,9 +116,9 @@ ReceiveSharedInvalidMessages(
 
        while (nextmsg < nummsgs)
        {
-           SharedInvalidationMessage *msg = &messages[nextmsg++];
+           SharedInvalidationMessage msg = messages[nextmsg++];
 
-           invalFunction(msg);
+           invalFunction(&msg);
        }
 
        /*