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 will add this also, if it looks simple to do so. Even if we yank it out later better to have the code for discussion purposes than just a conceptual bikeshed. > 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. Same situation as in archiving. The debate was eventually carried that we should have archive_mode = on archive_xxxx = NNNN for additional parameters > 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? Well, it can't even enter HS mode, so no error needed. > 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. I'm more comfortable running a new machine when it has an "off" switch. -- 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