* Greg Stark <gsst...@mit.edu> [100226 15:10]: > On Fri, Feb 26, 2010 at 7:16 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > I don't see a "substantial additional burden" there. What I would > > imagine is needed is that the slave transmits a single number back > > --- its current oldest xmin --- and the walsender process publishes > > that number as its transaction xmin in its PGPROC entry on the master. > > And when we want to support cascading slaves? > > Or when you want to bring up a new slave and it suddenly starts > advertising a new xmin that's older than the current oldestxmin? > > But in any case if I were running a reporting database I would want it > to just stop replaying logs for a few hours while my big batch report > runs, not cause the master to be unable to vacuum any dead records for > hours. That defeats much of the purpose of running the queries on the > slave.
*I* would be quite happy having the stop--and-go and the closed-loop be the only 2 modes of operation, and I'ld even be quite happy if the were both limited to separate method: 1) Running SR - then you are forced to use a closed-loop 2) Running HS from a backup/archive - forced to use stop-n-go #1 still needs to deal ith a slave "disappearing" and not advancing xmin for a period (TCP timeout)? I'll note that until SR does synchronous streaming rep (which will likely require some close-loop plan to allow the slave to be hot), I want situation #2, and hopefully the knob to control how long it allows a "stop" before going again can be a HUP'able knob so I can change it occasionally without taking the server down... -- Aidan Van Dyk Create like a god, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
signature.asc
Description: Digital signature
