Re: The case against multixact GUCs

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: The case against multixact GUCs
Date: 2014-04-16 18:10:52
Message-ID: 534EC7AC.5020505@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-04-16 18:22:21 Re: The case against multixact GUCs
Previous Message Peter Geoghegan 2014-04-16 18:07:02 Re: Clock sweep not caching enough B-Tree leaf pages?