The case against multixact GUCs - Mailing list pgsql-hackers

From Josh Berkus
Subject The case against multixact GUCs
Date
Msg-id 531F6085.7070909@agliodbs.com
Whole thread Raw
Responses Re: The case against multixact GUCs  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: The case against multixact GUCs  (David Johnston <polobo@yahoo.com>)
Re: The case against multixact GUCs  (Albe Laurenz <laurenz.albe@wien.gv.at>)
Re: The case against multixact GUCs  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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.

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*.

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
discussionof the new
 
GUCs hadn't been buried deep inside really long emails.

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.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] Store Extension Options
Next
From: Peter Eisentraut
Date:
Subject: logical decoding documentation?