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). So I'm not sure adding a flag before there's an actual need for it is necessarily going to be helpful. It may turn out to be insufficient even if we have a flag. And then there's the question of what the slave should do if the master was running without the flag. Do we make it throw an error? Does that mean the master needs to insert information to that effect in the wal logs? What if you shut down the master switch the flag and start it up again and you had a standby reading those logs all along. Will it be able to switch to HS mode now? We won't know until we know why this flag was necessary and what change in behaviour it might have caused. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers