Re: WIP: WAL prefetch (another approach)
От | Julien Rouhaud |
---|---|
Тема | Re: WIP: WAL prefetch (another approach) |
Дата | |
Msg-id | 20220314071713.v4anmngdi5njaple@jrouhaud обсуждение исходный текст |
Ответ на | Re: WIP: WAL prefetch (another approach) (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: WIP: WAL prefetch (another approach)
|
Список | pgsql-hackers |
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@gmail.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.
В списке pgsql-hackers по дате отправления: