On Sun, Dec 8, 2013 at 1:55 AM, huaicheng Li <lhcwhu@gmail.com> wrote:
> 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.
Since the invalidation queue is a ring buffer, it will eventually wrap
around, with new invalidation messages overwriting previously-written
ones. Once that happens, any backends that hadn't yet processed some
message that's since been overwritten have to be reset. Since there's
no longer any way of knowing exactly which parts of their
backend-local cache need to be flushed, they'll just have to flush
everything. That's the point of the lowbound.
However, that's expensive, so we want to prevent it from happening.
To do that, when we notice that a backend is way behind, we send it a
catchup signal. Hopefully, it will respond to the catchup signal by
reading the messages it hasn't yet processed from the queue. But if
it doesn't do that, or doesn't do it quickly enough, and more messages
keep arriving, then eventually the queue will wrap around and we'll
have to just reset it.
Does that help?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company