| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Standby catch up state change |
| Date: | 2013-10-16 10:15:20 |
| Message-ID: | 20131016101520.GC5319@awork2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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 well for all measurements, when we use a middleware
> which caches a lot of traffic on the sender side, this log message was very
> counter intuitive. It took several more minutes for the standby to actually
> receive all the WAL files and catch up after the message was displayed on
> the master side. But then as you said, may be relying on the message was
> not the best way to measure the time.
Query pg_stat_replication instead, that has the flush position.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavan Deolasee | 2013-10-16 10:30:18 | Re: Standby catch up state change |
| Previous Message | Vik Fearing | 2013-10-16 09:19:27 | Re: [PATCH] pg_sleep(interval) |