From: | Japin Li <japinli(at)hotmail(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Lock on ShmemVariableCache fields? |
Date: | 2022-10-31 02:48:01 |
Message-ID: | MEYP282MB16698F2B4CA6127A8D6E4085B6379@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi, hackers
The VariableCacheData says nextOid and oidCount are protected by
OidGenLock. However, we update them without holding the lock on
OidGenLock in BootStrapXLOG(). Same as nextXid, for other fields
that are protected by XidGenLock, it holds the lock, see
SetTransactionIdLimit().
void
BootStrapXLOG(void)
{
[...]
ShmemVariableCache->nextXid = checkPoint.nextXid;
ShmemVariableCache->nextOid = checkPoint.nextOid;
ShmemVariableCache->oidCount = 0;
[...]
SetTransactionIdLimit(checkPoint.oldestXid, checkPoint.oldestXidDB);
[...]
}
I also find a similar code in StartupXLOG(). Why we don't hold the lock
on OidGenLock when updating ShmemVariableCache->nextOid and
ShmemVariableCache->oidCount?
If the lock is unnecessary, I think adding some comments is better.
--
Regrads,
Japin Li.
ChengDu WenWu Information Technology Co.,Ltd.
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2022-10-31 02:56:28 | Re: Adding doubly linked list type which stores the number of items in the list |
Previous Message | Kyotaro Horiguchi | 2022-10-31 02:28:31 | Re: resowner "cold start" overhead |