> On 16-Oct-2013, at 3:45 pm, Andres Freund wrote:
>
>> On 2013-10-16 11:03:12 +0530, Pavan Deolasee wrote:
>> I think you are right. Someone who understands the replication code very
>> well advised us to use that log message as a way to measure how much time
>> it takes to send all the missin
On 2013-10-16 11:03:12 +0530, Pavan Deolasee wrote:
> I think you are right. Someone who understands the replication code very
> well advised us to use that log message as a way to measure how much time
> it takes to send all the missing WAL to a remote standby on a slow WAN
> link. While it worked
On Tue, Oct 15, 2013 at 4:51 PM, Andres Freund wrote:
>
>
> I think you're over-intrepreting it.
I think you are right. Someone who understands the replication code very
well advised us to use that log message as a way to measure how much time
it takes to send all the missing WAL to a remote sta
On 2013-10-15 16:29:47 +0530, Pavan Deolasee wrote:
> On Tue, Oct 15, 2013 at 4:16 PM, Andres Freund wrote:
>
> > I don't think delaying the message is a good
> > idea.
>
>
> Comment in walsender.c says:
>
> /*
> * If we're in catchup state, move to streaming. This i
On Tue, Oct 15, 2013 at 4:16 PM, Andres Freund wrote:
> I don't think delaying the message is a good
> idea.
Comment in walsender.c says:
/*
* If we're in catchup state, move to streaming. This is an
* important state change for users to know about, sinc
On 2013-10-15 16:12:56 +0530, Pavan Deolasee wrote:
> On Tue, Oct 15, 2013 at 3:59 PM, Andres Freund wrote:
>
> >
> > I don't think that'd be a good idea - the "caughtup" logic is used to
> > determine whether we need to wait for further wal to be generated
> > locally if we haven't got anything e
On Tue, Oct 15, 2013 at 3:59 PM, Andres Freund wrote:
>
> I don't think that'd be a good idea - the "caughtup" logic is used to
> determine whether we need to wait for further wal to be generated
> locally if we haven't got anything else to do. And we only need to do so
> when we reached the end o
On 2013-10-15 15:51:46 +0530, Pavan Deolasee wrote:
> Should we not instead wait for the standby to have received all the WAL
> before declaring that it has caught up ? If a failure happens while the
> data is still in the sender's buffer, the standby may not actually catch up
> to the desired poin
