Re: WIP: WAL prefetch (another approach)

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP: WAL prefetch (another approach)
Date: 2020-11-25 03:57:47
Message-ID: CA+hUKG+BEjLHiAxJEBw1QSckFJFL8Uq6EhAuqdK6KnavcHjefQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 19, 2020 at 10:00 AM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Thomas Munro (thomas(dot)munro(at)gmail(dot)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?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2020-11-25 04:13:56 Re: [PATCH] Add features to pg_stat_statements
Previous Message Tom Lane 2020-11-25 03:54:42 Re: About adding a new filed to a struct in primnodes.h