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 <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
