Re: Draft release notes for 9.4.4 et al - Mailing list pgsql-hackers

From Noah Misch
Subject Re: Draft release notes for 9.4.4 et al
Date
Msg-id 20150611063501.GA240412@tornado.leadboat.com
Whole thread Raw
In response to Re: Draft release notes for 9.4.4 et al  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
On Tue, Jun 09, 2015 at 04:31:43PM -0700, Josh Berkus wrote:
> First draft of the release announcement.

> 2015-06-12 Update Release
> =========================
> 
> The PostgreSQL Global Development Group has released an update to all supported versions of our database system,
including9.4.4, 9.3.9, 9.2.13, 9.1.18 and 9.0.22.  This release primarily fixes issues not successfully fixed in prior
releases.It should be applied as soon as possible by any user who installed the May or June update releases. Other
usersshould apply at the next available downtime.
 

The urgency is the same whether or not you installed the last couple of
releases: ASAP if you're on 9.3 or 9.4, next-downtime otherwise.  (A site on
9.4.1 doesn't have new problems, but the old problems were urgent enough.)

> Crash Recovery Fixes
> ---------------------
> 
> Earlier update releases attempted to fix an issue in PostgreSQL 9.3 and 9.4 with "multixact wraparound", but failed
toaccount for issues doing multixact cleanup during crash recovery.  This could cause servers to be unable to restart
aftera crash.  As such, all users of 9.3 and 9.4 should apply this update as soon as possible, expecially if they have
alreadyapplied updates 9.3.7, 9.3.8, 9.4.2 or 9.4.3.
 
> 
> Database administrators who used pg_upgrade to upgrade to PostgreSQL version 9.3 may find that applying the update
causesan immediate autovacuum of their entire database.  Please see the [release
notes](http://www.postgresql.org/docs/9.4/static/release-9-3-9.html)for details and ways to change the timing of the
vacuum.

This also affects sites that subsequently upgraded to 9.4.  (Your text doesn't
rule that out, but it bears mentioning explicitly.)  Also, I suggest saying a
bit more about the reasons for changing the timing of the vacuum.  Consider
this expansion of the second paragraph (but feel free to account for those
considerations other ways instead):
 Clusters previously upgraded to PostgreSQL 9.3 using pg_upgrade, even those clusters now running PostgreSQL 9.4 due to
anotherupgrade, may experience an immediate autovacuum of all tables after applying this update.  For large clusters,
considera controlled manual VACUUM, before updating, to better regulate the performance consequences of this critical
maintenance. See the release notes for details.
 

> Cumulative Releases
> -------------------
> 
> All PostgreSQL update releases are cumulative.  As this update release fixes a number of problems inadvertently
introducedby fixes in earlier update releases, we strongly urge users to apply this update, rather than installing less
recentupdates that have known issues.  As this update release closes all known bugs with multixact handling, the
PostgreSQLProject does not anticipate additional update releases soon.
 

It does not close all known bugs with multixact handling; see point (2) here,
for example:
http://www.postgresql.org/message-id/20150608131504.GH24997@alap3.anarazel.de

We nonetheless don't anticipate additional releases soon, but I would delete
the last sentence.



pgsql-hackers by date:

Previous
From: Abhijit Menon-Sen
Date:
Subject: Re: skipping pg_log in basebackup (was Re: pg_basebackup and pg_stat_tmp directory)
Next
From: Michael Paquier
Date:
Subject: Re: skipping pg_log in basebackup (was Re: pg_basebackup and pg_stat_tmp directory)