From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
---|---|
To: | Amul Sul <sulamul(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: CheckpointLock needed in CreateCheckPoint()? |
Date: | 2021-01-07 09:06:58 |
Message-ID: | CALj2ACV9MdyHB1Dsi-N9BMY7qf+0ndH=pZ2ynZgagK1zc-wB2Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jan 7, 2021 at 1:22 PM Amul Sul <sulamul(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | k.jamison@fujitsu.com | 2021-01-07 09:25:22 | RE: [Patch] Optimize dropping of relation buffers using dlist |
Previous Message | Amit Kapila | 2021-01-07 08:36:01 | Re: [Patch] Optimize dropping of relation buffers using dlist |