Josh Berkus wrote > Hackers, > > In the 9.3.3 updates, we added three new GUCs to control multixact > freezing. This was an unprecented move in my memory -- I can't recall > ever adding a GUC to a minor release which wasn't backwards > compatibility for a security fix. This was a mistake.
It probably should have been handled better but the decision to make these parameters visible itself doesn't seem to be the wrong decision - especially when limited to a fairly recently released back-branch. > What makes these GUCs worse is that nobody knows how to set them; nobody > on this list and nobody in the field. Heck, I doubt 1 in 1000 of our > users (or 1 in 10 people on this list) know what a multixact *is*. That isn't a reason in itself to not have the capability if it is actually needed. > Further, there's no clear justification why these cannot be set to be > the same as our other freeze ages (which our users also don't > understand), or a constant calculated portion of them, or just a > constant. Since nobody anticipated someone adding a GUC in a minor > release, there was no discussion of this topic that I can find; the new > GUCs were added as a "side effect" of fixing the multixact vacuum issue. > Certainly I would have raised a red flag if the discussion of the new > GUCs hadn't been buried deep inside really long emails. The release documentation makes a pointed claim that the situation WAS that the two were identical; but the different consumption rates dictated making the multi-xact configuration independently configurable. So in effect the GUC was always present - just not user-visible. Even if there are not any current "best practices" surrounding this topic at least this way as methods are developed there is an actual place to put the derived value. As a starting point one can simply look at the defaults and, if they have change the value for the non-multi value apply the same factor to the custom multi-version. Now, obviously someone has to think to actually do that - and the release notes probably should have provided such guidance - but as I state explicitly below the issue is more about insufficient communication and education and less about providing the flexibility. > Adding new GUCs which nobody has any idea how to set, or can even > explain to new users, is not a service to our users. These should be > removed. Or we should insist that those few that do have an understanding create some kind of wiki document, or even a documentation section, to educate those that are not as knowledgeable in this area. For good reason much of the recent focus in this area has been actually getting the feature to work. Presuming that it is a desirable feature - which it hopefully is given it made it into the wild - to have then such focus has obviously been necessary given the apparent complexity of this feature (as evidenced by the recent serious bug reports) but hopefully the feature itself is mostly locked down and education will begin. David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/The-case-against-multixact-GUCs-tp5795561p5795573.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers