On Sun, Dec 8, 2013 at 1:55 AM, huaicheng Li <lhc...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
