Received: from malur.postgresql.org ([217.196.149.56])
 by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from
 <pgsql-admin-owner+M42360=pgsql+2Dadmin=arkaria.postgresql.org@postgresql.org>)
 id 1WXqhL-00052q-Bt
 for pgsql-admin@arkaria.postgresql.org; Wed, 09 Apr 2014 11:29:43 +0000
Received: from localhost ([127.0.0.1] helo=postgresql.org)
 by malur.postgresql.org with smtp (Exim 4.80) (envelope-from
 <pgsql-admin-owner+M42360=pgsql+2Dadmin=arkaria.postgresql.org@postgresql.org>)
 id 1WXqhK-0002d5-Ci
 for pgsql-admin@arkaria.postgresql.org; Wed, 09 Apr 2014 11:29:42 +0000
Received: from makus.postgresql.org ([2001:4800:7903:4::125])
 by malur.postgresql.org with esmtp (Exim 4.80)
 (envelope-from <spoon@planet.ee>) id 1WXqhJ-0002cb-5l
 for pgsql-admin@postgresql.org; Wed, 09 Apr 2014 11:29:41 +0000
Received: from webmail.zone.eu ([217.146.65.70])
 by makus.postgresql.org with esmtp (Exim 4.80)
 (envelope-from <spoon@planet.ee>) id 1WXqhF-0003ij-42
 for pgsql-admin@postgresql.org; Wed, 09 Apr 2014 11:29:40 +0000
Received: from webmail.zone.ee (webmail.zone.eu [IPv6:2a02:29e8:700:0:1::70])
 by webmail.zone.eu (Postfix) with ESMTPA id 323EF2402B0A
 for <pgsql-admin@postgresql.org>; Wed,  9 Apr 2014 14:29:34 +0300 (EEST)
Received: from [195.222.11.180] (Authenticated sender: spoon@planet.ee)
 by webmail.zone.ee ([217.146.65.71]) with HTTP;
 Wed, 09 Apr 2014 14:29:34 +0300 (EEST)
From: "Viktor" <spoon@planet.ee>
To: "pgsql-admin@postgresql.org" <pgsql-admin@postgresql.org>
Subject: Update to 9.1.12
Date: Wed, 09 Apr 2014 14:29:34 +0300
X-Mailer: DataZone Webmail/2.4
X-Priority: 3
Message-ID: <1397042974.1665600d@webmail.zone.ee>
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--=_8dab9da4bc68981a4e1d578466d15578"
X-Pg-Spam-Score: 0.0 (/)
List-Archive: <http://archives.postgresql.org/pgsql-admin>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-admin.postgresql.org>
List-Owner: <mailto:pgsql-admin-owner@postgresql.org>
List-Post: <mailto:pgsql-admin@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-admin>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-admin>
X-Mailing-List: pgsql-admin
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org

----=_8dab9da4bc68981a4e1d578466d15578
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello,
=20
 We are currently running PostgreSQL version 9.1.9-1~bpo60+1 (Debian =
Squeeze) and would like to update it to 9.1 9.1.12-0wheezy1.
=20
 But there is one serious issue about this update:
=20
 "
 E.3.2. Changes =C2=A0
 Fix VACUUM's tests to see whether it can update relfrozenxid (Andres =
Freund)
 In some cases VACUUM (either manual or autovacuum) could incorrectly =
advance a table's relfrozenxid value, allowing tuples to escape freezing, =
causing those rows to become invisible once 2^31 transactions have =
elapsed. The probability of data loss is fairly low since multiple =
incorrect advancements would need to happen before actual loss occurs, but =
it's not zero. Users upgrading from releases 9.0.4 or 8.4.8 or earlier are =
not affected, but all later versions contain the bug.
 The issue can be ameliorated by, after upgrading, vacuuming all tables in =
all databases while having vacuum_freeze_table_age set to zero. This will =
fix any latent corruption but will not be able to fix all pre-existing =
data errors. However, an installation can be presumed safe after =
performing this vacuuming if it has executed fewer than 2^31 update =
transactions in its lifetime (check this with SELECT txid_current() < =
2^31).
 "
=20
 Please explain should I run VACUUM on all tables after the update if >
=20
 postgres=3D# SELECT txid_current() < 2^31;
 =C2=A0?column?
 ----------
 =C2=A0t
 (1 row)
=20
=20
 --
 Best regards,
 Viktor


----=_8dab9da4bc68981a4e1d578466d15578
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello,<br />
<br />
We are currently running PostgreSQL version 9.1.9-1~bpo60+1 (Debian =
Squeeze) and would like to update it to 9.1 9.1.12-0wheezy1.<br />
<br />
But there is one serious issue about this update:<br />
<br />
"<br />
E.3.2. Changes
<h2 class=3D"SECT2">&#160;</h2>
<p>Fix <tt class=3D"COMMAND">VACUUM</tt>'s tests to see         whether it =
can update <tt class=3D"STRUCTFIELD">relfrozenxid</tt> (Andres Freund)</p>
<p>In some cases <tt class=3D"COMMAND">VACUUM</tt> (either         manual =
or autovacuum) could incorrectly advance a table's         <tt =
class=3D"STRUCTFIELD">relfrozenxid</tt> value, allowing         tuples to =
escape freezing, causing those rows to become         invisible once 2^31 =
transactions have elapsed. The         probability of data loss is fairly =
low since multiple         incorrect advancements would need to happen =
before actual         loss occurs, but it's not zero. Users upgrading from =
        releases 9.0.4 or 8.4.8 or earlier are not affected, but         =
all later versions contain the bug.</p>
<p>The issue can be ameliorated by, after upgrading,         vacuuming all =
tables in all databases while having <a =
href=3D"http://www.postgresql.org/docs/9.1/static/runtime-config-client.htm=
l#GUC-VACUUM-FREEZE-TABLE-AGE"><tt class=3D"VARNAME">         =
vacuum_freeze_table_age</tt></a> set to zero. This will fix         any =
latent corruption but will not be able to fix all         pre-existing =
data errors. However, an installation can be         presumed safe after =
performing this vacuuming if it has         executed fewer than 2^31 =
update transactions in its         lifetime (check this with <tt =
class=3D"LITERAL">SELECT         txid_current() &lt; 2^31</tt>).</p>
"<br />
<br />
Please explain should I run VACUUM on all tables after the update if =
&gt;<br />
<br />
postgres=3D# SELECT txid_current() &lt; 2^31;<br />
&#160;?column?<br />
----------<br />
&#160;t<br />
(1 row)<br />
<br />
<br />
--<br />
Best regards,<br />
Viktor<br />

----=_8dab9da4bc68981a4e1d578466d15578--