Re: [HACKERS] Standby catch up state change

2013-10-16 Thread Andres Freund
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

Re: [HACKERS] Standby catch up state change

2013-10-16 Thread Pavan Deolasee
On 16-Oct-2013, at 3:45 pm, Andres Freund and...@2ndquadrant.com 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

[HACKERS] Standby catch up state change

2013-10-15 Thread Pavan Deolasee
Hello, I wonder if there is an issue with the way state change happens from WALSNDSTATE_CATCHUP to WALSNDSTATE_STREAMING. Please note my question is solely based on a strange behavior reported by a colleague and my limited own code reading. The colleague is trying out replication with a

Re: [HACKERS] Standby catch up state change

2013-10-15 Thread Andres Freund
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 point

Re: [HACKERS] Standby catch up state change

2013-10-15 Thread Pavan Deolasee
On Tue, Oct 15, 2013 at 3:59 PM, Andres Freund and...@2ndquadrant.comwrote: 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

Re: [HACKERS] Standby catch up state change

2013-10-15 Thread Andres Freund
On 2013-10-15 16:12:56 +0530, Pavan Deolasee wrote: On Tue, Oct 15, 2013 at 3:59 PM, Andres Freund and...@2ndquadrant.comwrote: 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

Re: [HACKERS] Standby catch up state change

2013-10-15 Thread Pavan Deolasee
On Tue, Oct 15, 2013 at 4:16 PM, Andres Freund and...@2ndquadrant.comwrote: 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

Re: [HACKERS] Standby catch up state change

2013-10-15 Thread Andres Freund
On 2013-10-15 16:29:47 +0530, Pavan Deolasee wrote: On Tue, Oct 15, 2013 at 4:16 PM, Andres Freund and...@2ndquadrant.comwrote: I don't think delaying the message is a good idea. Comment in walsender.c says: /* * If we're in catchup state, move to

Re: [HACKERS] Standby catch up state change

2013-10-15 Thread Pavan Deolasee
On Tue, Oct 15, 2013 at 4:51 PM, Andres Freund and...@2ndquadrant.comwrote: 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