Re: Reducing the cost of sinval messaging

On Mon, Oct 27, 2014 at 3:31 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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 sure they 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.

We did quite a bit of testing at the time and found that it was a
clear improvement over what we had been doing previously.  Of course,
that's not to say we can't or shouldn't improve it further.

> 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.

It was discussed at the time:

http://www.postgresql.org/message-id/CA+TgmoY3Q56ZR6i8h+iGhXCw6rCZyvdWJ3RQT=PMVev4-=+N_g@mail.gmail.com
http://www.postgresql.org/message-id/13077.1311702188@sss.pgh.pa.us

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company