Re: Replication & recovery_min_apply_delay

Поиск
Список
Период
Сортировка
От Asim R P
Тема Re: Replication & recovery_min_apply_delay
Дата
Msg-id CANXE4Tf4ptAB52M9s8H10SU3LHDzmCwrPL3HQuK7zXiWoFZsSw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Replication & recovery_min_apply_delay  (Asim Rama Praveen <apraveen@pivotal.io>)
Ответы Re: Replication & recovery_min_apply_delay
Список pgsql-hackers
On Mon, Jan 27, 2020 at 5:11 PM Asim Rama Praveen <apraveen@pivotal.io> wrote:
>
> The following review has been posted through the commitfest application:
> make installcheck-world:  not tested
> Implements feature:       not tested
> Spec compliant:           not tested
> Documentation:            not tested
>
> The logic to start WAL receiver early should not be coupled with recovery_min_apply_delay GUC.  WAL receiver's delayed start affects replication in general, even when the GUC is not set.
>
> A better fix would be to start WAL receiver in the main replay loop, as soon as consistent state has been reached.
>
> As noted during previous reviews, scanning all WAL just to determine streaming start point seems slow.  A faster solution seems desirable.
>
> The new status of this patch is: Waiting on Author

That review is for Konstantin's patch "wal_apply_delay-2.patch".  The latest patch on this thread addresses the above review comments, so I've changed the status in commitfest app back to "needs review".

Asim

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Asim Rama Praveen
Дата:
Сообщение: Re: Replication & recovery_min_apply_delay
Следующее
От: Robert Haas
Дата:
Сообщение: Re: making the backend's json parser work in frontend code