Re: WIP: WAL prefetch (another approach) - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: WIP: WAL prefetch (another approach)
Date
Msg-id CA+hUKG+BEjLHiAxJEBw1QSckFJFL8Uq6EhAuqdK6KnavcHjefQ@mail.gmail.com
Whole thread Raw
In response to Re: WIP: WAL prefetch (another approach)  (Stephen Frost <sfrost@snowman.net>)
Responses Re: WIP: WAL prefetch (another approach)  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Thu, Nov 19, 2020 at 10:00 AM Stephen Frost <sfrost@snowman.net> wrote:
> * Thomas Munro (thomas.munro@gmail.com) wrote:
> > Hmm.  Every time I try to think of a protocol change for the
> > restore_command API that would be acceptable, I go around the same
> > circle of thoughts about event flow and realise that what we really
> > need for this is ... a WAL receiver...
>
> A WAL receiver, or an independent process which goes out ahead and
> fetches WAL..?

What I really meant was: why would you want this over streaming rep?
I just noticed this thread proposing to retire pg_standby on that
basis:

https://www.postgresql.org/message-id/flat/20201029024412.GP5380%40telsasoft.com

I'd be happy to see that land, to fix this problem with my plan.  But
are there other people writing restore scripts that block that would
expect them to work on PG14?



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: About adding a new filed to a struct in primnodes.h
Next
From: Fujii Masao
Date:
Subject: Re: [PATCH] Add features to pg_stat_statements