Skip site navigation (1) Skip section navigation (2)

TRUE/FALSE vs true/false

From: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
To: pgsql-hackers(at)postgresql(dot)org
Subject: TRUE/FALSE vs true/false
Date: 2011-08-04 10:08:21
Message-ID: 4E3A6F95.3030104@cybertec.at (view raw or flat)
Thread:
Lists: pgsql-hackers
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(at)localhost backend]$ find . -name "*.c" | xargs grep -w true | grep -v 'true"' | grep
= | wc -l
2446
[zozo(at)localhost backend]$ find . -name "*.c" | xargs grep -w false | grep -v 'false"' |
grep = | wc -l
2745
[zozo(at)localhost backend]$ find . -name "*.c" | xargs grep -w TRUE | grep -v 'TRUE"' | grep
= | wc -l
119
[zozo(at)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/


Responses

pgsql-hackers by date

Next:From: Boszormenyi ZoltanDate: 2011-08-04 12:13:18
Subject: New WIP patch for cross column statistics Re: TEXT vs PG_NODE_TREE in system columns (cross column and expression statistics patch)
Previous:From: Pavel StehuleDate: 2011-08-04 09:12:55
Subject: Re: Postgres / plpgsql equivalent to python's getattr() ?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group