Postgres Pro
Downloads
Home   >   mailing lists

Thread: shared buffers and startup process

shared buffers and startup process

From
Joao Junior
Date:
Hi, 
I have a master slave setup with streaming replication.
I have a lots of wal files that were moved from master but not applied yet , a big delay in the replica.
The replica is not working on  hotstandby mode ,  no conflicts to delay  wals apply  on it.

I would like to know if  increasing the amount of shared-buffers could help the startup process applying the wals. I would like to know if in the process of reading the wals and applying them,  blocks that should be written will be  brought to shared buffer or not?? If yes, having a bigger shared buffer will keep as much as possible the amount of pages there and increase the startup process's speed avoiding pages's replacement and going to the OS cache and maybe to the disk .
Does it make sense?

Thanks in advanced.

Regards,
Joao


Re: shared buffers and startup process

From
Michael Paquier
Date:
On Tue, Jan 14, 2020 at 04:29:51PM +0100, Joao Junior wrote:
> I would like to know if  increasing the amount of shared-buffers could help
> the startup process applying the wals. I would like to know if in
> the process of reading the wals and applying them,  blocks that should be
> written will be  brought to shared buffer or not??

Please feel free to look at XLogReadBufferForRedo() in xlogutils.c and
check what the routine does, and when/where it gets called.  The code
is well-documented, so you will find your answer easily.

> If yes, having a bigger
> shared buffer will keep as much as possible the amount of pages there and
> increase the startup process's speed avoiding pages's replacement and going
> to the OS cache and maybe to the disk .
> Does it make sense?

It does.  Even if relying on the OS cache would be enough in most
cases, it is good to keep a certain of pages hot enough, and you need
to be careful with not setting shared_buffers too high either.
--
Michael
Attachment