Re: The case against multixact GUCs

On Wed, Mar 12, 2014 at 12:45 PM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> On 03/12/2014 06:26 PM, Robert Haas wrote:
>> On Tue, Mar 11, 2014 at 3:14 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>>> 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.
>>
>> I disagree. I think it was the right decision. I think it was a
>> mistake not including all of that stuff in the first place, and I
>> think it's good that we've now corrected that oversight.
>
> In hindsight, I think permanent multixids in their current form was a
> mistake. Before 9.3, the thing that made multixids special was that they
> could just be thrown away at a restart. They didn't need freezing. Now that
> they do, why not just use regular XIDs for them?

Well, the numbering of MXIDs is closely bound up with their storage
format. To do what you're proposing, we'd need to invent some new way
of associating an XID-used-as-MXID with update XID, list of lockers,
and lock modes. Which is certainly possible, but it's not obvious
that it's a good idea.

I *am* concerned that we didn't adequately weigh the costs of adding
another thing that has to be frozen before we did it. Clearly, the
feature has a lot of benefit, or will once we've flushed out most of
the bugs. But it's hard to say at this point how much the cost is
going to be, and I do think that's cause for concern. But I'm not
convinced that unifying the XID and MXID spaces would have addressed
that concern to any measurable degree.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company