On Thu, Jan 20, 2011 at 8:54 PM, Kevin Grittner <kevin.gritt...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers