Jakub Ouhrabka <kuba@xxxxxxxxxx> writes:
> We'we tried hard to identify what's the cause of filling sinval-queue.
> We went through query logs as well as function bodies stored in the
> database. We were not able to find any DDL, temp table creations etc.
Strange. The best idea that comes to mind is to add some debugging
code to SendSharedInvalidMessage to log the content of each message
that's sent out. That would at least tell us *what* is going into
the queue, even if not directly *why*. Try something like (untested)
void
SendSharedInvalidMessage(SharedInvalidationMessage *msg)
{
bool insertOK;
+ elog(LOG, "sending inval msg %d %u %u %u %u %u",
+ msg->cc.id,
+ msg->cc.tuplePtr.ip_blkid.bi_hi,
+ msg->cc.tuplePtr.ip_blkid.bi_lo,
+ msg->cc.tuplePtr.ip_posid,
+ msg->cc.dbId,
+ msg->cc.hashValue);
+
LWLockAcquire(SInvalLock, LW_EXCLUSIVE);
insertOK = SIInsertDataEntry(shmInvalBuffer, msg);
LWLockRelease(SInvalLock);
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
