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

  1. Add Valgrind buffer access instrumentation.

  2. Fix wrong merge resolution making pg_receivexlog fail in 9.2.