Thread: pgsql: First-draft release notes for 9.3.3.
First-draft release notes for 9.3.3. As usual, the release notes for older branches will be made by cutting these down, but put them up for community review first. Branch ------ master Details ------- http://git.postgresql.org/pg/commitdiff/cefd3e507d7cc402225e5da100d05dcafb90c0bd Modified Files -------------- doc/src/sgml/release-9.3.sgml | 1253 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1253 insertions(+)
Hi Tom,
Some comments on the release notes:
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [423e1211a] 2014-01-10 18:03:18 -0300
Branch: REL9_3_STABLE [a25c2b7c4] 2014-01-10 18:03:18 -0300
-->
<listitem>
<para>
Fix multixact freezing of tuples that predate
a <literal>pg_upgrade</> to 9.3
(Álvaro Herrera)
</para>
<para>
This oversight would result in complaints such as <quote>ERROR:
MultiXactId 11415437 does no longer exist -- apparent wraparound</>.
</para>
</listitem>
I *think* this could only happen with changes that were committed
*after* 9.3.2 has been released. Alvaro, that's right, no?
Are such issues listed?
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [e8312b4f0] 2013-12-13 11:50:15 -0500
Branch: REL9_3_STABLE [478af9b79] 2013-12-13 11:50:25 -0500
-->
<listitem>
<para>
Prevent timeout interrupts from taking control away from mainline
code unless <varname>ImmediateInterruptOK</> is set
(Andres Freund, Tom Lane)
</para>
<para>
This was initially reported as a <quote>stuck spinlock</> failure,
but many other misbehaviors are possible after a statement timeout.
</para>
</listitem>
I think this needs to be featured more prominently. It's the reason I
have been asking for a new pointrelease... Issues I've seen this cause
*in production* on several sites since the the fix was committed
include:
* ERRORs regularly being promoted to PANICs on seemingly innocous errors
because CriticalSectionCount is out of whack.
* backends spuriously holding lwlocks which do not get cleaned up
because there's no LWLockReleaseAll() call unless
TRANS_INPROGRESS/START has been reached. That sometimes got "fixed" when
backends exited because there happens to be a LWLockReleaseAll() call
there. Symptoms included backends waiting on themselves and clusters
getting stuck until certain backends exited.
* backends that were unkillable because InterruptHoldoffCount whas out
of whack.
* corrupted heap pages
All but the last one were occurring repeatedly, and have completely
vanished since applying the fix. The last one I have seen only once, but
it seems like quite a comfortable explanation.
With the current explanation it's going to be hard to convince people
how important it is to upgrade from 9.3.2 to 9.3.3.
Thanks for assembling the notes,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Andres Freund wrote:
> Hi Tom,
>
> Some comments on the release notes:
>
> <!--
> Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
> Branch: master [423e1211a] 2014-01-10 18:03:18 -0300
> Branch: REL9_3_STABLE [a25c2b7c4] 2014-01-10 18:03:18 -0300
> -->
>
> <listitem>
> <para>
> Fix multixact freezing of tuples that predate
> a <literal>pg_upgrade</> to 9.3
> (Álvaro Herrera)
> </para>
>
> <para>
> This oversight would result in complaints such as <quote>ERROR:
> MultiXactId 11415437 does no longer exist -- apparent wraparound</>.
> </para>
> </listitem>
>
> I *think* this could only happen with changes that were committed
> *after* 9.3.2 has been released. Alvaro, that's right, no?
Yes, the problem was introduced in
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [3b97e6823] 2013-12-16 11:29:50 -0300
Branch: REL9_3_STABLE [8e9a16ab8] 2013-12-16 11:29:51 -0300
Rework tuple freezing protocol
and 9.3.2 had been tagged two weeks earlier (strangely, I don't see
"Release: 9.3.2" in git_changelog output, even though I just pulled).
So only people using a git checkout would see it.
Maybe this doesn't event warrant a release note entry.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Andres Freund wrote:
>> I *think* this could only happen with changes that were committed
>> *after* 9.3.2 has been released. Alvaro, that's right, no?
> Yes, the problem was introduced in [3b97e6823]
> Maybe this doesn't event warrant a release note entry.
Agreed, if the bug was never in any shipped version. I was planning
to ask if there were any other commits that could be left out, or
merged --- it feels like this set of notes is a bit too blow-by-blow.
regards, tom lane