Re: [CORE] postpone next week's release
Heikki Linnakangas <hlinnaka@iki.fi>
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Andres Freund <andres@anarazel.de>
Cc: Bruce Momjian <bruce@momjian.us>, Robert Haas <robertmhaas@gmail.com>,
Tom Lane <tgl@sss.pgh.pa.us>, Stephen Frost <sfrost@snowman.net>,
Magnus Hagander <magnus@hagander.net>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
pgsql-core <pgsql-core@postgresql.org>
Date: 2015-06-04T09:27:50Z
Lists: pgsql-hackers
On 06/04/2015 12:17 PM, Andres Freund wrote: > On 2015-06-04 11:51:44 +0300, Heikki Linnakangas wrote: >> So, I'm all for refactoring and adding abstractions where it makes sense, >> but it's not going to solve design problems. > > I personally don't really see the multixact changes being that bad on > the overall design. It pretty much just extended an earlier design. Now > that wasn't great, but I don't think too many people had realized that > at that point. The biggest problem was underestimating the complexity. Yeah, many of the issues were pre-existing, and would've been good to fix anyway. The multixact issues remind me of the another similar thing we did: the visibility map. It too was non-critical when it was first introduced, but later we started using it for index-only-scans, and it suddenly became important that it's up-to-date and crash-safe. We did uncover some bugs in that area when index-only-scans were introduced, similar to the multixact bugs, only not as bad because it didn't lead to data loss. I don't have any point to make with that comparison, but it was similar in many ways. - Heikki
Commits
-
Add Valgrind buffer access instrumentation.
- 1e0dfd166b3f 14.0 landed
-
Fix wrong merge resolution making pg_receivexlog fail in 9.2.
- 6b700301c36e 9.2.11 cited