Re: 9.5 release notes

On Fri, Jun 19, 2015 at 09:44:04PM +0200, Andres Freund wrote:
> Hi,
>
> On 2015-06-11 00:15:21 -0400, Bruce Momjian wrote:
> > I have committed the first draft of the 9.5 release notes. You can view
> > the output here:
>
> I'm looking through all the commits, checking which I think should
> possibly be mentioned additionally:
> - 9f03ca91 - Speed up CREATE INDEX by avoiding to copy index tuples

I can't see this information being useful to our general users.

> - 9da86753 - Reject duplicate column names in foreign key referenced-columns lists.
> behavioural change, should be documented as intentional

Uh, well, I didn't think such uses were common, and we now issue a very
clear error message, so I didn't think it was worth mentioning.

> - 680513ab - Break out OpenSSL-specific code to separate files.
> should perhaps be mentioned in the developer section.

I usually only mention code changes that would affect extension authors,
or massive changes.

> - 0709b7ee7 - Change the spinlock primitives to function as compiler barriers.
> Significant behavioural change for developers.

Uh, again, not really for the group of developers I usually worry about
in the release notes.

> - 94028691 - Advance backend's advertised xmin more aggressively.
> Pretty good feature imo.

Yeah, but again, do our general users understand enough to even
understand the explaination, and even if they do, do they care.

> - 5028f22f6 - Switch to CRC-32C in WAL and other places.
> This might have compability impact in some external tools.

Agreed, text updated:

Speed up <acronym>CRC</> (cyclic redundancy check) computations
and switch to CRC-32C (Abhijit Menon-Sen, Heikki Linnakangas)

> - 4f1b890b1 -
> Unsure if this should be mentioned, at least it's a fairly
> large change.

This is:

Merge the various forms of transaction commit & abort records.

Again, much too internal-focused for our users to care.

> - 27846f02 - Optimize locking a tuple already locked by another subxact
> Several users ran into this slowness, so I think we should mention the
> optimization.

I usually don't mention speedup of edge cases. There are problably a
few people who care about it though, but this will be read by thousands
of people.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +