Re: WIP: WAL prefetch (another approach)

On Mon, Mar 14, 2022 at 06:15:59PM +1300, Thomas Munro wrote:
> On Fri, Mar 11, 2022 at 9:27 PM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
> > > > Also, is it worth an assert (likely at the top of the function) for that?
> > >
> > > How could I assert that EndRecPtr has the right value?
> >
> > Sorry, I meant to assert that some value was assigned (!XLogRecPtrIsInvalid).
> > It can only make sure that the first call is done after XLogBeginRead /
> > XLogFindNextRecord, but that's better than nothing and consistent with the top
> > comment.
>
> Done.

Just a small detail: I would move that assert at the top of the function as it
should always be valid.
>
> I also fixed the compile failure with -DWAL_DEBUG, and checked that
> output looks sane with wal_debug=on.

Great! I'm happy with 0001 and I think it's good to go!
>
> > > The other thing I need to change is that I should turn on
> > > recovery_prefetch for platforms that support it (ie Linux and maybe
> > > NetBSD only for now), in the tests. Right now you need to put
> > > recovery_prefetch=on in a file and then run the tests with
> > > "TEMP_CONFIG=path_to_that make -C src/test/recovery check" to
> > > excercise much of 0002.
> >
> > +1 with Andres' idea to have a "try" setting.
>
> Done. The default is still "off" for now, but in
> 027_stream_regress.pl I set it to "try".

Great too! Unless you want to commit both patches right now I'd like to review
0002 too (this week), as I barely look into it for now.