Robert Haas wrote: > Kevin Grittner 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. That depends on whether we can pull off the idea for not sending the snapshot itself which I mentioned. But that idea is pretty sketchy at the moment. I can't swear we can make that work, but if we can, it should use a lot less WAL space. > 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. If we can make that work, that has advantages. > 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? Unfortunately, to get a safe snapshot you need to grab a candidate snapshot and wait for all serializable read write transactions which were active at the time to complete. At a minimum. If any of them develop the wrong pattern of rw-dependencies you have to discard it, grab a new snapshot, and try again. I suspect that most of the time you will succeed on the first snapshot, and so will be able to call it safe when the last concurrent serializable read write transaction completes, but that *could* be a long time, and there is no upper bound. That's why I was suggesting that we try to keep a fairly current safe snapshot sitting on the standby and use it when a serializable transaction is requested. Unless you request DEFERRABLE, in which case you would wait for the *next* one to arrive. I keep looking for another angle on this, but I'm not finding it. I've *thought* I had something a couple times this evening while tossing it around in my head, but the ideas fall apart on closer inspection. :-( -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
