On Tue, Jun 21, 2022 at 4:55 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Tue, Jun 21, 2022 at 3:18 PM Andrey Borodin <x4...@yandex-team.ru> wrote: > > > > > On 21 Jun 2022, at 12:35, Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > > > I wonder if the newly introduced "recovery_prefetch" [1] for PG-15 can > > > help your case? > > > > AFAICS recovery_prefetch tries to prefetch main fork, but does not try to > > prefetch WAL itself before reading it. Kirill is trying to solve the > > problem of reading WAL segments that are our of OS page cache. > > > > Okay, but normally the WAL written by walreceiver is read by the > startup process soon after it's written as indicated in code comments > (get_sync_bit()). So, what is causing the delay here which makes the > startup process perform physical reads?
That's not always true. If there's a huge apply lag and/or restartpoint is infrequent/frequent or there are many reads on the standby - in all of these cases the OS cache can replace the WAL from it causing the startup process to hit the disk for WAL reading. Regards, Bharath Rupireddy.
