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
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? |