Re: Replication & recovery_min_apply_delay

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Cc: Mahendra Singh Thalor <mahi6run(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Asim R P <apraveen(at)pivotal(dot)io>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Konstantin Knizhnik <knizhnik(at)garret(dot)ru>, Hao Wu <hawu(at)pivotal(dot)io>
Subject: Re: Replication & recovery_min_apply_delay
Date: 2021-11-22 10:54:53
Message-ID: CALj2ACXV+ybgWuGbi1AR=pLwoQJBrOxkheB4E=B+2LJ=KN2iow@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Nov 14, 2021 at 11:45 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> On Wed, Oct 27, 2021 at 1:01 AM Mahendra Singh Thalor
> <mahi6run(at)gmail(dot)com> wrote:
>
> I was going through and patch and trying to understand the idea that
> what we are trying to achieve here. So basically, generally we start
> the WAL receiver when we want to fetch the WAL, but if the user has
> set the parameter WAL_RCV_START_AT_CONSISTENCY then we will start
> fetching the WAL using walreciver in advance. IMHO the benefit of
> this idea is that with the GUC we can control whether the extra WAL
> will be collected at the primary or at the standby node right?
>
> One problem is that if the currentsource is XLOG_FROM_ARCHIVE then we
> might fetch the WAL using both walreceiver as well as from archive
> right? because we are not changing the currentsource. Is this
> intentional or do we want to change the currentsource as well?

Is there any relation between this patch and another one at [1]?

[1] https://www.postgresql.org/message-id/9AA68455-368B-484A-8A53-3C3000187A24%40yesql.se

Regards,
Bharath Rupireddy.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marek Kulik 2021-11-22 10:57:46 Building postgresql armv7 on emulated x86_64
Previous Message Bharath Rupireddy 2021-11-22 10:53:28 Re: Unnecessary delay in streaming replication due to replay lag