On Mon, Oct 27, 2014 at 3:31 PM, Tom Lane <t...@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...@mail.gmail.com
http://www.postgresql.org/message-id/13077.1311702...@sss.pgh.pa.us
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
