About shared cache invalidation mechanism

From: huaicheng Li <lhcwhu(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us
Subject: About shared cache invalidation mechanism
Date: 2013-12-08 06:55:57
Message-ID: CANr0WEcSf=t5qU_Cw1S9B-gU7RwtK=cmeorGPGM-KxNLHNO4PQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2013-12-08 08:45:01 Re: plpgsql_check_function - rebase for 9.3
Previous Message Amit Kapila 2013-12-08 04:39:20 Re: Extra functionality to createuser