[HACKERS] TRUE/FALSE vs true/false

[Boszormenyi Zoltan]

Hi,

I looked at b4fbe392f8ff6ff1a66b488eb7197eef9e1770a4
and I noticed that it's using TRUE, FALSE, true and false
inconsistently:

@@ -248,6 +249,7 @@ CreateSharedInvalidationState(void)
                shmInvalBuffer->procState[i].nextMsgNum = 0;    /* meaningless 
*/
                shmInvalBuffer->procState[i].resetState = false;
                shmInvalBuffer->procState[i].signaled = false;
+               shmInvalBuffer->procState[i].hasMessages = false;
                shmInvalBuffer->procState[i].nextLXID = 
InvalidLocalTransactionId;
        }
 }

@@ -316,6 +316,7 @@ SharedInvalBackendInit(bool sendOnly)
        stateP->nextMsgNum = segP->maxMsgNum;
        stateP->resetState = false;
        stateP->signaled = false;
+       stateP->hasMessages = false;
        stateP->sendOnly = sendOnly;
 
        LWLockRelease(SInvalWriteLock);


@@ -459,6 +461,19 @@ SIInsertDataEntries(const SharedInvalidationMessage *data, 
int n)
                        SpinLockRelease(&vsegP->msgnumLock);
                }
 
+               /*
+                * 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;
+               }
+
                LWLockRelease(SInvalWriteLock);
        }
 }

@@ -499,11 +514,36 @@ SIGetDataEntries(SharedInvalidationMessage *data, int 
datasize)
...
+        * Note that, if we don't end up reading all of the messages, we had
+        * better be certain to reset this flag before exiting!
+        */
+       stateP->hasMessages = FALSE;
+

@@ -544,10 +584,16 @@ SIGetDataEntries(SharedInvalidationMessage *data, int 
datasize)
...
        if (stateP->nextMsgNum >= max)
                stateP->signaled = false;
+       else
+               stateP->hasMessages = TRUE;


Also, grepping for checking for or assigning bool values reveal that
"true" and "false" are used far more than "TRUE" and "FALSE":

[zozo@localhost backend]$ find . -name "*.c" | xargs grep -w true | grep -v 
'true"' | grep
= | wc -l
2446
[zozo@localhost backend]$ find . -name "*.c" | xargs grep -w false | grep -v 
'false"' |
grep = | wc -l
2745
[zozo@localhost backend]$ find . -name "*.c" | xargs grep -w TRUE | grep -v 
'TRUE"' | grep
= | wc -l
119
[zozo@localhost backend]$ find . -name "*.c" | xargs grep -w FALSE | grep -v 
'FALSE"' |
grep = | wc -l
140

Shouldn't these get fixed to be consistent?

Best regards,
Zoltán Böszörményi

-- 
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
     http://www.postgresql.at/


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers