From: | Zhang Mingli <zmlpostgres(at)gmail(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Japin Li <japinli(at)hotmail(dot)com> |
Subject: | Re: Lock on ShmemVariableCache fields? |
Date: | 2022-10-31 06:15:49 |
Message-ID: | 2f0598a2-4fa3-4f94-8fe5-8a481a0f8732@Spark |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
HI,
On Oct 31, 2022, 10:48 +0800, Japin Li <japinli(at)hotmail(dot)com>, wrote:
>
> 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.
>
>
As its name BootStrapXLOG, it’s used in BootStrap mode to initialize the template database.
The process doesn’t speak SQL and the database is not ready.
There won’t be concurrent access to variables.
Regards,
Zhang Mingli
>
From | Date | Subject | |
---|---|---|---|
Next Message | Bharath Rupireddy | 2022-10-31 06:20:27 | Re: Use pg_pwritev_with_retry() instead of write() in dir_open_for_write() to avoid partial writes? |
Previous Message | Bharath Rupireddy | 2022-10-31 06:05:44 | Re: Adding doubly linked list type which stores the number of items in the list |