On 2014-04-16 11:10:52 -0700, Josh Berkus wrote:
> 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?
Ripping multixacts out in general? Err, right. We'd loose shared row
level locks...
I think ripping out stuff at this point would be the cause of many, many
more bugs than it'd prevent.
> 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.
Sorry, but I think you're blowing some GUCs *WAY* out of proportion.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services