Re: WIP: WAL prefetch (another approach)

From: David Steele <david(at)pgmasters(dot)net>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP: WAL prefetch (another approach)
Date: 2020-04-08 12:27:39
Message-ID: 226b5950-7404-a51d-8dc7-53895b363a38@pgmasters.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 4/8/20 8:12 AM, Thomas Munro wrote:
>
> Ok, so the following parts of this work have been committed:
>
> b09ff536: Simplify the effective_io_concurrency setting.
> fc34b0d9: Introduce a maintenance_io_concurrency setting.
> 3985b600: Support PrefetchBuffer() in recovery.
> d140f2f3: Rationalize GetWalRcv{Write,Flush}RecPtr().
>
> However, I didn't want to push the main patch into the tree at
> (literally) the last minute after doing such much work on it in the
> last few days, without more review from recovery code experts and some
> independent testing.

I definitely think that was the right call.

> Judging by the comments made in this thread and
> elsewhere, I think the feature is in demand so I hope there is a way
> we could get it into 13 in the next couple of days, but I totally
> accept the release management team's prerogative on that.

That's up to the RMT, of course, but we did already have an extra week.
Might be best to just get this in at the beginning of the PG14 cycle.
FWIW, I do think the feature is really valuable.

Looks like you'll need to rebase, so I'll move this to the next CF in
WoA state.

Regards,
--
-David
david(at)pgmasters(dot)net

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2020-04-08 12:29:07 Re: Vacuum o/p with (full 1, parallel 0) option throwing an error
Previous Message Masahiko Sawada 2020-04-08 12:25:59 Re: [bug] Wrong bool value parameter