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?
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 |