On Mon, Nov 22, 2021 at 4:25 PM Bharath Rupireddy
wrote:
>
> On Sun, Nov 14, 2021 at 11:45 AM Dilip Kumar wrote:
> >
> > On Wed, Oct 27, 2021 at 1:01 AM Mahendra Singh Thalor
> > wrote:
> >
> > I was going through and patch and trying to understand the idea that
> > what we are trying to achieve
On Sun, Nov 14, 2021 at 11:45 AM Dilip Kumar wrote:
>
> On Wed, Oct 27, 2021 at 1:01 AM Mahendra Singh Thalor
> 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 t
On Wed, Oct 27, 2021 at 1:01 AM Mahendra Singh Thalor
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_STA
Thanks Dilip and Bharath for the review.
I am working on review comments and will post an updated patch.
On Wed, 10 Nov 2021 at 15:31, Bharath Rupireddy
wrote:
>
> On Wed, Oct 27, 2021 at 1:02 AM Mahendra Singh Thalor
> wrote:
> > On Mon, 3 Aug 2020 at 15:02, Daniel Gustafsson wrote:
> >>
> >>
On Wed, Oct 27, 2021 at 1:02 AM Mahendra Singh Thalor
wrote:
> On Mon, 3 Aug 2020 at 15:02, Daniel Gustafsson wrote:
>>
>> This thread has stalled and the patch no longer applies, so I'm marking this
>> Returned with Feedback. Please feel free to open a new entry if this patch
>> is
>> revived.
On Wed, Oct 27, 2021 at 1:01 AM Mahendra Singh Thalor
wrote:
>
>
> On Mon, 3 Aug 2020 at 15:02, Daniel Gustafsson wrote:
>>
>> This thread has stalled and the patch no longer applies, so I'm marking this
>> Returned with Feedback. Please feel free to open a new entry if this patch
>> is
>> revi
> On 26 Oct 2021, at 21:31, Mahendra Singh Thalor wrote:
> I took v3[1] patch from this thread and re-based on commit
> head(5fedf7417b69295294b154a21).
>
> Please find the attached patch for review.
Cool! There is a Commitfest starting soon, as the previous entry was closed
you need to open
On Mon, 3 Aug 2020 at 15:02, Daniel Gustafsson wrote:
> This thread has stalled and the patch no longer applies, so I'm marking
> this
> Returned with Feedback. Please feel free to open a new entry if this
> patch is
> revived.
>
> cheers ./daniel
>
>
Hi all,
I took v3[1] patch from this thread
This thread has stalled and the patch no longer applies, so I'm marking this
Returned with Feedback. Please feel free to open a new entry if this patch is
revived.
cheers ./daniel
A key challenge here is how to determine the starting point for WAL
receiver when the startup process starts it while still replaying WAL
that's already received. Hao and I wrote a much faster and less intrusive
solution to determine the starting point. Scan the first page of each WAL
segment fil
On Mon, Jan 27, 2020 at 5:11 PM Asim Rama Praveen
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
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_mi
Replay lag can build up naturally, even when recovery_min_apply_delay
is not set, because WAL generation on master is concurrent and WAL
replay on standby is performed by a single process.
Hao and I have incorporated the new GUC from Konstantin's patch
and used it to start WAL receiver in the main
On Fri, Nov 15, 2019 at 06:48:01PM +0300, Konstantin Knizhnik wrote:
> Attached pleased find rebased version of the patch with
> "wal_receiver_start_condition" GUC added (preserving by default original
> behavior).
Konstantin, please be careful with the patch entry in the CF app.
This was marked a
On 15.11.2019 5:52, Michael Paquier wrote:
On Tue, Sep 10, 2019 at 03:23:25PM +0900, Michael Paquier wrote:
Yes, I suspect that it could be very costly in some configurations if
there is a large gap between the last replayed LSN and the last LSN
the WAL receiver has flushed.
There is an extra
On Tue, Sep 10, 2019 at 03:23:25PM +0900, Michael Paquier wrote:
> Yes, I suspect that it could be very costly in some configurations if
> there is a large gap between the last replayed LSN and the last LSN
> the WAL receiver has flushed.
>
> There is an extra thing, which has not been mentioned y
On Tue, Sep 10, 2019 at 12:46:49AM +0300, Alexander Korotkov wrote:
> On Wed, Sep 4, 2019 at 4:37 PM Konstantin Knizhnik
> wrote:
>> receivedUpto is just static variable in xlog.c, maintained by WAL receiver.
>> But as I mentioned above, WAL receiver is not started at the moment when
>> we need to
On Wed, Sep 4, 2019 at 4:37 PM Konstantin Knizhnik
wrote:
> receivedUpto is just static variable in xlog.c, maintained by WAL receiver.
> But as I mentioned above, WAL receiver is not started at the moment when
> we need to know LSN of last record.
>
> Certainly it should be possible to somehow pe
On 04.09.2019 1:22, Alvaro Herrera wrote:
On 2019-Aug-02, Michael Paquier wrote:
On Wed, Jul 31, 2019 at 04:43:26PM -0400, Alvaro Herrera wrote:
As for the test module, the one I submitted takes a lot of time to run
(well, 60s) and I don't think it's a good idea to include it as
something t
On 2019-Aug-02, Michael Paquier wrote:
> On Wed, Jul 31, 2019 at 04:43:26PM -0400, Alvaro Herrera wrote:
> > As for the test module, the one I submitted takes a lot of time to run
> > (well, 60s) and I don't think it's a good idea to include it as
> > something to be run all the time by every buil
On Wed, Jul 31, 2019 at 04:43:26PM -0400, Alvaro Herrera wrote:
> As for the test module, the one I submitted takes a lot of time to run
> (well, 60s) and I don't think it's a good idea to include it as
> something to be run all the time by every buildfarm member. I'm not
> sure that there's a lea
On 2019-Jul-31, Konstantin Knizhnik wrote:
> On 08.07.2019 11:05, Michael Paquier wrote:
> > Please note that I have not looked at that stuff in details, but I
> > find the patch proposed kind of ugly with the scan of the last segment
> > using a WAL reader to find out what is the last LSN and re
On 08.07.2019 11:05, Michael Paquier wrote:
On Mon, Jul 08, 2019 at 07:56:25PM +1200, Thomas Munro wrote:
On Thu, Jan 31, 2019 at 3:34 AM Alvaro Herrera wrote:
On 2019-Jan-30, Konstantin Knizhnik wrote:
I wonder if it can be considered as acceptable solution of the problem or
there can be
On Mon, Jul 08, 2019 at 07:56:25PM +1200, Thomas Munro wrote:
> On Thu, Jan 31, 2019 at 3:34 AM Alvaro Herrera
> wrote:
> > On 2019-Jan-30, Konstantin Knizhnik wrote:
> > > I wonder if it can be considered as acceptable solution of the problem or
> > > there can be some better approach?
> >
> > I
On Thu, Jan 31, 2019 at 3:34 AM Alvaro Herrera wrote:
> On 2019-Jan-30, Konstantin Knizhnik wrote:
> > I wonder if it can be considered as acceptable solution of the problem or
> > there can be some better approach?
>
> I didn't find one.
It sounds like you are in agreement that there is a proble
Hi
On 2019-Jan-30, Konstantin Knizhnik wrote:
> One of our customers was faced with the following problem: he has
> setup physical primary-slave replication but for some reasons
> specified very large (~12 hours) recovery_min_apply_delay.
We also came across this exact same problem some time ag
26 matches
Mail list logo
