Re: WIP: WAL prefetch (another approach)

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: WIP: WAL prefetch (another approach)
Дата
Msg-id CA+hUKG+BEjLHiAxJEBw1QSckFJFL8Uq6EhAuqdK6KnavcHjefQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: WIP: WAL prefetch (another approach)  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: WIP: WAL prefetch (another approach)  (Stephen Frost <sfrost@snowman.net>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: About adding a new filed to a struct in primnodes.h
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: [PATCH] Add features to pg_stat_statements