On Fri, May 8, 2015 at 2:27 PM, Andres Freund <and...@anarazel.de> wrote: > On 2015-05-08 14:15:44 -0400, Robert Haas wrote: >> Apparently, we have been hanging our hat since the release of 9.3.0 on >> the theory that the average multixact won't ever have more than two >> members, and therefore the members SLRU won't overwrite itself and >> corrupt data. > > It's essentially a much older problem - it has essentially existed since > multixacts were introduced (8.1?). The consequences of it were much > lower before 9.3 though.
OK, I wasn't aware of that. What exactly were the consequences before 9.3? > I'm not inclined to backport it at this stage. Maybe if we get some > field reports about too many anti-wraparound vacuums due to this, *and* > the code has been tested in 9.5. That was about what I was thinking, too. >> Another thought that occurs to me is that if we had a freeze map, it >> would radically decrease the severity of this problem, because >> freezing would become vastly cheaper. I wonder if we ought to try to >> get that into 9.5, even if it means holding up 9.5 > > I think that's not realistic. Doing this right isn't easy. And doing it > wrong can lead to quite bad results, i.e. data corruption. Doing it > under the pressure of delaying a release further and further seems like > recipe for disaster. Those are certainly good things to worry about. > FWIW, I intend to either work on this myself, or help whoever seriously > tackles this, in the next cycle. That would be great. I'll investigate what resources EnterpriseDB can commit to this. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers