Reducing the cost of sinval messaging

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Reducing the cost of sinval messaging
Дата
Msg-id 26896.1414438281@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: Reducing the cost of sinval messaging
Список pgsql-hackers
I happened to be looking at sinvaladt.c and noticed the loop added in
commit b4fbe392f8ff6ff1a66b488eb7197eef9e1770a4:
       /*        * Now that the maxMsgNum change is globally visible, we give everyone        * a swift kick to make
surethey read the newly added messages.        * Releasing SInvalWriteLock will enforce a full memory barrier, so
* these (unlocked) changes will be committed to memory before we exit        * the function.        */       for (i =
0;i < segP->lastBackend; i++)       {           ProcState  *stateP = &segP->procState[i];
 
           stateP->hasMessages = true;       }

This seems fairly awful when there are a large number of backends.

Why could we not remove the hasMessages flags again, and change the
unlocked test
if (!stateP->hasMessages)    return 0;

into
if (stateP->nextMsgNum == segP->maxMsgNum &&    !stateP->resetState)    return 0;

If we are looking at stale shared state, this test might produce a
false positive, but I don't see why it's any less safe than testing a
hasMessages boolean.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thom Brown
Дата:
Сообщение: Re: TODO request: log_long_transaction
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Reducing the cost of sinval messaging