On Wed, 2009-11-25 at 03:12 +0000, Greg Stark wrote: > On Wed, Nov 25, 2009 at 2:10 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > As long as there's not anything the master actually does differently > > then I can't see where there'd be any performance testing to do. What's > > bothering me about this is that it seems likely that we'll find places > > where the master has to do things differently. I'd rather we made the > > status visible; if we get through a release cycle without needing to > > check it, we can always take the function out again. But if we don't, > > and then find out midway through the 8.5 release cycle that we need to > > be able to check it, things could be a bit sticky. > > Well the only thing that's been discussed is having vacuum require a > minimum age before considering a transaction visible to all to reduce > the chance of conflicts on cleanup records. But that would require an > actual tunable, not just a flag. And it's something that could > conceivably be desirable even if you're not running a HS setup (if > someone ever reimplements time travel for example).
I've added "vacuum_delay_cleanup_age = N", default 0 to implement this. New name please. This alters the return value of GetOldestXmin() and the setting of RecentGlobalXmin by the value requested. I've made this a SIGHUP, since it only has value if it affects all users. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers