On 2013-12-01 18:56:19 -0500, Tom Lane wrote:
> I've put up draft notes at
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=23e796de15567e9d31e8f9e8661828179f24a7be
> and they should be visible on the docs website at
> http://www.postgresql.org/docs/devel/static/release-9-3-2.html
> in half an hour or so, after guaibasaurus does its next buildfarm run.
> I'd like to do any required editing on the notes at this stage,
> before I start extracting relevant subsets for the older branches.
When do you plan to backpatch the documentation?
> * is it useful to go into more detail than this about the data corruption
> bugs? It's not clear to me that we can say more than "vacuum and re-clone
> your standbys" as far as recovery actions go, at least not within the
> couple of sentences that we traditionally allow for a release note item.
I think it might be worth mentioning that (parts) of the data are
potentially recoverable without too much effort in all of the bugs.
> * is there anything important to be said about the fourth and fifth bullet
> points ("Fix bugs in setting the visibility-map bit for an empty page"
I doubt it's worth mentioning that one. Pretty much the only possible
consequence is hitting an Assert() in assert enabled builds in a pretty
rare scenario. There's no data corruption.
Except maybe the fact that the original fix (a6370fd9) wasn't mentioned
in the last round of release notes, and that was more frequent and could
persistently break crash recovery, by erroring out with "PANIC: WAL
contains references to invalid pages" errors.
> and "Fix multiple bugs in update chain traversal")?
4c71f48f4c6c923d1b3f6e6c788e8a0995f4241a
2a4b6eed0916a8fdc57b4778ecb1463fe752d369
663d2e485e4d526770ab618469d875c404714119
These have quite some possible consequences though. Not sure how to
describe it in few words, but it could lead to updating, locking or
returning the wrong row (by following into a different ctid chain),
unneccessary deadlocks (by unneccesarily waiting for an entire
multixact's member, instead of just the updater), missed and superflous
serialization failures in repeatable read and, slightly differently, in
serializable. All need concurrency to manifest.
In that context, commit fbface6f946242571f4acbfa9a74727c073748ba maybe
should be mentioned as well: spurious "unable to fetch updated version
of tuple" ERRORs.
Not sure whether f5f92bdc44ffdf577244e0d055825cacd0cdea10,
d9484ab5f3cbcfea64536fec333723f9aa4c0b2c shouldn't be mentioned
separately, especially the first could cause autovacuum to crazily spawn
children without ever actually doing anything useful.
> Are any of those likely to be sources of data corruption that would
> persist past the upgrade?
In so far that a query could have updated/returned something wrong,
yes. I don't think we usually list that kind of problem as corruption?
> * any other items that need to be corrected or expanded?
<para>
Fix <command>VACUUM</>'s tests to see whether it can
update <structfield>relfrozenxid</> (Andres Freund, Sergey Burladyn,
Jeff Janes)
</para>
I think Sergey's and Jeff's fix
(4c697d8f4845823a8af67788b219ffa4516ad14c) deserves its own
headline. The problem there was that a scan_all vacuum could end up not
updating relfrozenxid. That doesn't cause corruption but possibly
superflous further full table/anti-wraparound vacuums or even not
accepting writes anymore outside of single user mode thingy (do we have
a good name for that?). Only affects 9.2+.
<para>
Fix initialization of <filename>pg_clog</> and
<filename>pg_subtrans</>
during hot standby startup (Andres Freund)
</para>
I think Heikki spent a fair amount of time looking at the code, so it
seems fair to also name him as well..
Maybe we should mention that hot_standby=on is a prerequisite?
<para>
Truncate <filename>pg_multixact</> contents during crash recovery
(Andres Freund)
</para>
<para>
This avoids ever-increasing disk space consumption in hot standby
mode.
</para>
It's not really related to hot standby - anything that never comes out
of crash recovery is affected. We sometime should come up with a
coherent name that covers HS, SR, PITR, warm standbys et al...
Should the strerror() improvements be mentioned
(e3480438e89f74019f271b1b5501bb9eed2e0d2a)?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
