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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
