On Thu, Jan 20, 2011 at 8:54 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> As I mentioned in another email, we might want to throttle this. My
> thinking was that we could start a timer on capturing a snapshot, and
> continue to gather new ones as they become available. When you hit
> the timer limit (maybe 100ms?) you send the latest snapshot, if you
> have a new one; otherwise you keep trying and send one as soon as you
> get it.
I think this is likely to suck. That's introducing 10 not-small XLOG
records per second just in case someone happens to try to start a
serializable transaction on a standby server.
A possibly-viable alternative would be to build something into the SR
protocol to allow the standby to request a workable snapshot from the
master, and the master to send it (out-of-band with respect to the WAL
stream) when so requested. Then it wouldn't work if you lose the
connection to the master, but maybe that's OK. Even with that, it
seems like there could be starvation problems - is there an upper
bound on the length of time it would take the master to generate a
safe snapshot for the standby to use?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
