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.


Andres Freund

 Andres Freund                     http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to