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

From Josh Berkus
Subject Re: The case against multixact GUCs
Date
Msg-id 534EC7AC.5020505@agliodbs.com
Whole thread Raw
In response to The case against multixact GUCs  (Josh Berkus <josh@agliodbs.com>)
Responses Re: The case against multixact GUCs  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On 03/12/2014 09:45 AM, Heikki Linnakangas wrote:
> 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.

So, if we ripped out all the multixact stuff for 9.4, what would that
cost us?  I'm serious.  The multixact stuff has been broken since 9.3
was released, and it's *still* broken.  We can't give users any guidance
or tools on how to set multixact stuff, and autovacuum doesn't handle it
properly.

Seems like this was just a bad patch and we should rip it out.  What
features do we lose?

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



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Clock sweep not caching enough B-Tree leaf pages?
Next
From: Andres Freund
Date:
Subject: Re: The case against multixact GUCs