Re: The case against multixact GUCs - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: The case against multixact GUCs
Date
Msg-id 53208F1E.8030100@vmware.com
Whole thread Raw
In response to Re: The case against multixact GUCs  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: The case against multixact GUCs
List pgsql-hackers
On 03/12/2014 06:26 PM, Robert Haas wrote:
> On Tue, Mar 11, 2014 at 3:14 PM, Josh Berkus <josh@agliodbs.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? We had to 
duplicate much of the wraparound and freezing logic for multixids that 
simply would not have been an issue if we had used regular XIDs instead.

We could've perhaps kept the old multixids for their original purpose, 
as transient xids that can be forgotten about after all the old 
snapshots are gone. But for the permanent ones, it would've been simpler 
if we handled them more like subxids; make them part of the same XID 
space as regular XIDs.

This is pretty hand-wavy of course, and it's too late now.

- Heikki



pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: pgstat wait timeout (RE: contrib/cache_scan)
Next
From: Tom Lane
Date:
Subject: Re: pgstat wait timeout (RE: contrib/cache_scan)