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.