Thread: Do we need pre-allocate WAL files during end-of-recovery checkpoint?

Hi,

The function PreallocXlogFiles doesn't get called during
end-of-recovery checkpoint in CreateCheckPoint, see [1]. The server
becomes operational after the end-of-recovery checkpoint and may need
WAL files. However, I'm not sure how beneficial it is going to be if
the WAL is pre-allocated (as PreallocXlogFiles just allocates only 1
extra WAL file).

Thoughts?

[1]
    /*
     * An end-of-recovery checkpoint is really a shutdown checkpoint, just
     * issued at a different time.
     */
    if (flags & (CHECKPOINT_IS_SHUTDOWN | CHECKPOINT_END_OF_RECOVERY))
        shutdown = true;
    else
        shutdown = false;

    /*
     * Make more log segments if needed.  (Do this after recycling old log
     * segments, since that may supply some of the needed files.)
     */
    if (!shutdown)
        PreallocXlogFiles(recptr, checkPoint.ThisTimeLineID);

Regards,
Bharath Rupireddy.

On 12/6/21, 4:54 AM, "Bharath Rupireddy" <bharath.rupireddyforpostgres@gmail.com> wrote:
> The function PreallocXlogFiles doesn't get called during
> end-of-recovery checkpoint in CreateCheckPoint, see [1]. The server
> becomes operational after the end-of-recovery checkpoint and may need
> WAL files. However, I'm not sure how beneficial it is going to be if
> the WAL is pre-allocated (as PreallocXlogFiles just allocates only 1
> extra WAL file).

There is another thread for adding more effective WAL pre-allocation
[0] that you might be interested in.

Nathan

[0] https://www.postgresql.org/message-id/flat/20201225200953.jjkrytlrzojbndh5%40alap3.anarazel.de

On Mon, Dec 06, 2021 at 06:21:40PM +0530, Bharath Rupireddy wrote:
> The function PreallocXlogFiles doesn't get called during
> end-of-recovery checkpoint in CreateCheckPoint, see [1]. The server
> becomes operational after the end-of-recovery checkpoint and may need
> WAL files.

PreallocXlogFiles() is never a necessity; it's just an attempted optimization.
I expect preallocation at end-of-recovery would do more harm than good,
because the system would accept no writes at all while waiting for it.

> However, I'm not sure how beneficial it is going to be if
> the WAL is pre-allocated (as PreallocXlogFiles just allocates only 1
> extra WAL file).

Yeah, PreallocXlogFiles() feels like a relict from the same era that gave us
checkpoint_segments=3.  It was more useful before commit 63653f7 (2002).

On Tue, Dec 7, 2021 at 1:02 AM Bossart, Nathan <bossartn@amazon.com> wrote:
>
> On 12/6/21, 4:54 AM, "Bharath Rupireddy" <bharath.rupireddyforpostgres@gmail.com> wrote:
> > The function PreallocXlogFiles doesn't get called during
> > end-of-recovery checkpoint in CreateCheckPoint, see [1]. The server
> > becomes operational after the end-of-recovery checkpoint and may need
> > WAL files. However, I'm not sure how beneficial it is going to be if
> > the WAL is pre-allocated (as PreallocXlogFiles just allocates only 1
> > extra WAL file).
>
> There is another thread for adding more effective WAL pre-allocation
> [0] that you might be interested in.
> [0] https://www.postgresql.org/message-id/flat/20201225200953.jjkrytlrzojbndh5%40alap3.anarazel.de

I haven't had a chance to go through the entire thread but I have a
quick question: why can't the walwriter pre-allocate some of the WAL
segments instead of a new background process? Of course, it might
delay the main functionality of the walwriter i.e. flush and sync the
WAL files, but having checkpointer do the pre-allocation makes it do
another extra task. Here the amount of walwriter work vs checkpointer
work, I'm not sure which one does more work compared to the other.

Another idea could be to let walwrtier or checkpointer pre-allocate
the WAL files whichever seems free as-of-the-moment when the WAL
segment pre-allocation request comes. We can go further to let the
user choose which process i.e. checkpointer or walwrtier do the
pre-allocation with a GUC maybe?

I will also put the same thoughts in the "Pre-allocating WAL files"
thread so that we can continue the discussion there.

[1] https://www.postgresql.org/message-id/20201225200953.jjkrytlrzojbndh5%40alap3.anarazel.de

Regards,
Bharath Rupireddy.

On Tue, Dec 7, 2021 at 12:09 PM Noah Misch <noah@leadboat.com> wrote:
>
> On Mon, Dec 06, 2021 at 06:21:40PM +0530, Bharath Rupireddy wrote:
> > The function PreallocXlogFiles doesn't get called during
> > end-of-recovery checkpoint in CreateCheckPoint, see [1]. The server
> > becomes operational after the end-of-recovery checkpoint and may need
> > WAL files.
>
> PreallocXlogFiles() is never a necessity; it's just an attempted optimization.
> I expect preallocation at end-of-recovery would do more harm than good,
> because the system would accept no writes at all while waiting for it.

Yeah. At times, end-of-recovery checkpoint itself will take a good
amount of time and adding to it the pre-allocation of WAL time doesn't
make sense.

> > However, I'm not sure how beneficial it is going to be if
> > the WAL is pre-allocated (as PreallocXlogFiles just allocates only 1
> > extra WAL file).
>
> Yeah, PreallocXlogFiles() feels like a relict from the same era that gave us
> checkpoint_segments=3.  It was more useful before commit 63653f7 (2002).

I see.

Regards,
Bharath Rupireddy.

On Tue, Dec 7, 2021 at 12:35 AM SATYANARAYANA NARLAPURAM
<satyanarlapuram@gmail.com> wrote:
>
> If the segment size is 16MB it shouldn't take much time but higher segment values this can be a problem. But again,
thecurrent segment has to be filled 75% to precreate new one. I am not sure how much we gain. Do you have some numbers
withdifferent segment sizes? 

I don't have the numbers. However I agree that the pre-allocation can
make end-of-recovery checkpoint times more. At times, the
end-of-recovery checkpoint itself will take a good amount of time and
adding to it the pre-allocation of WAL time doesn't make sense.

Regards,
Bharath Rupireddy.