About shared cache invalidation mechanism - Mailing list pgsql-hackers

From huaicheng Li
Subject About shared cache invalidation mechanism
Date
Msg-id CANr0WEcSf=t5qU_Cw1S9B-gU7RwtK=cmeorGPGM-KxNLHNO4PQ@mail.gmail.com
Whole thread
Responses Re: About shared cache invalidation mechanism
List pgsql-hackers
​I know that all invalid cache messages are stored in the shmInvalidationBuffer ring buffer and that they should be consumed by all other backends to keep their own cache fresh. Since there may be some "stragglers" which process the SI message quite slow, we use *catchup* interrupt(signal) to accelerate their cosuming shared invalid messages. Here comes my questions :
(1). When the current number of messages in the shmInvalidationBuffer exceeds a threshold, it needs to be cleaned up by using SICleanupQueue. After that, if the number still exceeds MAXNUMMESSAGES/2, threshold will be calculated by the following formula:
Threshold = (numMsgs/CLEANUP_QUANTUM + 1) * CLEANUP_QUANTUM
(2). For those slow backends, if their *nextMsgNum* value is less than *lowbound*, they will be reset, and the *lowbound* is calculated by
lowbound = maxMsgNum - MAXNUMMESSAGES + minFree,
and if their *nextMsgNum* value is less than *minsig*, they will get catchup signals to speed up, *minsig* is calculated by
minsig = maxMsgNum - MAXNUMMESSAGES/2

Here, I want to ask why threshold, lowbound and minsig are calculated like that ? Do the three formulas have any performance considerations when designed ? I have searched through the old mail list archives, but found nothing about these(these changes emerged in pg8.4 firstly), any help would be appreciated.

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Extra functionality to createuser
Next
From: Pavel Stehule
Date:
Subject: Re: plpgsql_check_function - rebase for 9.3