Re: CheckpointLock needed in CreateCheckPoint()?
От | Bharath Rupireddy |
---|---|
Тема | Re: CheckpointLock needed in CreateCheckPoint()? |
Дата | |
Msg-id | CALj2ACV9MdyHB1Dsi-N9BMY7qf+0ndH=pZ2ynZgagK1zc-wB2Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: CheckpointLock needed in CreateCheckPoint()? (Amul Sul <sulamul@gmail.com>) |
Список | pgsql-hackers |
On Thu, Jan 7, 2021 at 1:22 PM Amul Sul <sulamul@gmail.com> wrote: > I am not sure I understood your point completely. Do you mean there could be > multiple bootstrap or standalone backends that could exist at a time and can > perform checkpoint? Actually, my understanding of the standalone backend was wrong initially. Now, I'm clear with that. > > I don't think we can completely get rid of CheckpointLock in > > CreateCheckPoint given the fact that it can get called from multiple > > processes. > > > > How? When the server is run in a standalone backend, it seems like there can be only one process running in single user mode, as pointed by Dilip upthread, so there will be no simultaneous calls to CreateCheckPoint. > > How about serving that ASRO barrier request alone for checkpointer > > process in ProcessInterrupts even though the CheckpointLock is held by > > the checkpointer process? And also while the checkpointing is > > happening, may be we should call CHECK_FOR_INTERRUPTS to see if the > > ASRO barrier has arrived. This may sound bit hacky, but just a > > thought. I'm thinking that in ProcessInterrupts we can get to know the > > checkpointer process type via MyAuxProcType, and whether the lock is > > held or not using CheckpointLock, and then we can handle the ASRO > > global barrier request. > > > > I am afraid that this will easily get rejected by the community. Note that this > is a very crucial code path of the database server. There are other options > too, but don't want to propose them until clarity on the CheckpointLock > necessity. I understand that. I'm sorry, if I have sidetracked the main point here. With Regards, Bharath Rupireddy. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: