| From: | Greg Stark <gsstark(at)mit(dot)edu> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Keepalive for max_standby_delay |
| Date: | 2010-06-03 15:43:54 |
| Message-ID: | AANLkTinziZwRWdTdAnc7XiaOr0DYuY56GX47shmST5s_@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jun 3, 2010 at 4:34 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> The data keeps coming in and getting dumped into the slave's pg_xlog.
> walsender/walreceiver are not at all tied to the slave's application
> of WAL. In principle we could have the code around max_standby_delay
> notice just how far behind it's gotten and adjust the delay tolerance
> based on that; but I think designing a feedback loop for that is 9.1
> material.
Er, no. In that case my first concern was misguided. I'm happy there's
no feedback loop -- my fear was that there was and it would mean the
"time received" could be decoupled from the time the wal was
generated. But as you describe it then the time received might be
slightly delayed from the time the wal was generated but to some
constant degree -- not in a way that will be influenced by the log
application being blocked on the slave.
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2010-06-03 15:44:17 | Re: functional call named notation clashes with SQL feature |
| Previous Message | Tom Lane | 2010-06-03 15:34:43 | Re: Keepalive for max_standby_delay |