Re: Replication & recovery_min_apply_delay - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: Replication & recovery_min_apply_delay
Date
Msg-id CAFiTN-srf2CD_6bH7PnVY042s0dKQNUsN=UbJLF21Ste8PiGyg@mail.gmail.com
Whole thread Raw
In response to Re: Replication & recovery_min_apply_delay  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
List pgsql-hackers
On Mon, Nov 22, 2021 at 4:25 PM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
>
> On Sun, Nov 14, 2021 at 11:45 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> >
> > On Wed, Oct 27, 2021 at 1:01 AM Mahendra Singh Thalor
> > <mahi6run@gmail.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

Seems like both of them are trying to solve the same issue.

-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: jsonb crash
Next
From: Greg Nancarrow
Date:
Subject: Windows build warnings