Re: Replication & recovery_min_apply_delay
От | Dilip Kumar |
---|---|
Тема | Re: Replication & recovery_min_apply_delay |
Дата | |
Msg-id | CAFiTN-srf2CD_6bH7PnVY042s0dKQNUsN=UbJLF21Ste8PiGyg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Replication & recovery_min_apply_delay (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Список | 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 по дате отправления: