Re: Lock on ShmemVariableCache fields?

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
>

In response to

Responses

Browse pgsql-hackers by date

  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