| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| 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-02 17:44:26 |
| Message-ID: | 4C06987A.5040306@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> I'm still inclined to apply the part of Simon's patch that adds a
> transmit timestamp to each SR send chunk. That would actually be
> completely unused by the slave given my proposal above, but I think that
> it is an important step to take to future-proof the SR protocol against
> possible changes in the slave-side timing logic.
>
+1.
From a radically different perspective, I had to do something similar
in the buildfarm years ago to protect us from machines reporting with
grossly inaccurate timestamps. This was part of the solution. The client
adds its current timestamp setting just before transmitting the data to
the server.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chris Browne | 2010-06-02 17:45:34 | Re: Exposing the Xact commit order to the user |
| Previous Message | Greg Smith | 2010-06-02 17:37:59 | Re: Synchronization levels in SR |