Linux SRV-16 6.18.44-paas #1 SMP PREEMPT_DYNAMIC Thu Aug 13 10:08:12 UTC 2026 x86_64
/
proc
/
thread-self
/
root
/
opt
/
postgresql-11
/
doc
/
html
/
//proc/thread-self/root/opt/postgresql-11/doc/html/release-9-3-9.html
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>E.75. Release 9.3.9</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets V1.79.1" /><link rel="prev" href="release-9-3-10.html" title="E.74. Release 9.3.10" /><link rel="next" href="release-9-3-8.html" title="E.76. Release 9.3.8" /></head><body><div xmlns="http://www.w3.org/TR/xhtml1/transitional" class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">E.75. Release 9.3.9</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="release-9-3-10.html" title="E.74. Release 9.3.10">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="release.html" title="Appendix E. Release Notes">Up</a></td><th width="60%" align="center">Appendix E. Release Notes</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 11.1 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="release-9-3-8.html" title="E.76. Release 9.3.8">Next</a></td></tr></table><hr></hr></div><div class="sect1" id="RELEASE-9-3-9"><div class="titlepage"><div><div><h2 class="title" style="clear: both">E.75. Release 9.3.9</h2></div></div></div><div class="toc"><dl class="toc"><dt><span class="sect2"><a href="release-9-3-9.html#id-1.11.6.79.4">E.75.1. Migration to Version 9.3.9</a></span></dt><dt><span class="sect2"><a href="release-9-3-9.html#id-1.11.6.79.5">E.75.2. Changes</a></span></dt></dl></div><p><strong>Release date: </strong>2015-06-12</p><p> This release contains a small number of fixes from 9.3.8. For information about new features in the 9.3 major release, see <a class="xref" href="release-9-3.html" title="E.84. Release 9.3">Section E.84</a>. </p><div class="sect2" id="id-1.11.6.79.4"><div class="titlepage"><div><div><h3 class="title">E.75.1. Migration to Version 9.3.9</h3></div></div></div><p> A dump/restore is not required for those running 9.3.X. </p><p> However, if you are upgrading an installation that was previously upgraded using a <span class="application">pg_upgrade</span> version between 9.3.0 and 9.3.4 inclusive, see the first changelog entry below. </p><p> Also, if you are upgrading from a version earlier than 9.3.7, see <a class="xref" href="release-9-3-7.html" title="E.77. Release 9.3.7">Section E.77</a>. </p></div><div class="sect2" id="id-1.11.6.79.5"><div class="titlepage"><div><div><h3 class="title">E.75.2. Changes</h3></div></div></div><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p> Fix possible failure to recover from an inconsistent database state (Robert Haas) </p><p> Recent <span class="productname">PostgreSQL</span> releases introduced mechanisms to protect against multixact wraparound, but some of that code did not account for the possibility that it would need to run during crash recovery, when the database may not be in a consistent state. This could result in failure to restart after a crash, or failure to start up a secondary server. The lingering effects of a previously-fixed bug in <span class="application">pg_upgrade</span> could also cause such a failure, in installations that had used <span class="application">pg_upgrade</span> versions between 9.3.0 and 9.3.4. </p><p> The <span class="application">pg_upgrade</span> bug in question was that it would set <code class="literal">oldestMultiXid</code> to 1 in <code class="filename">pg_control</code> even if the true value should be higher. With the fixes introduced in this release, such a situation will result in immediate emergency autovacuuming until a correct <code class="literal">oldestMultiXid</code> value can be determined. If that would pose a hardship, users can avoid it by doing manual vacuuming <span class="emphasis"><em>before</em></span> upgrading to this release. In detail: </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p> Check whether <span class="application">pg_controldata</span> reports <span class="quote">“<span class="quote">Latest checkpoint's oldestMultiXid</span>”</span> to be 1. If not, there's nothing to do. </p></li><li class="listitem"><p> Look in <code class="filename">PGDATA/pg_multixact/offsets</code> to see if there's a file named <code class="filename">0000</code>. If there is, there's nothing to do. </p></li><li class="listitem"><p> Otherwise, for each table that has <code class="structname">pg_class</code>.<code class="structfield">relminmxid</code> equal to 1, <code class="command">VACUUM</code> that table with both <a class="xref" href="runtime-config-client.html#GUC-VACUUM-MULTIXACT-FREEZE-MIN-AGE">vacuum_multixact_freeze_min_age</a> and <a class="xref" href="runtime-config-client.html#GUC-VACUUM-MULTIXACT-FREEZE-TABLE-AGE">vacuum_multixact_freeze_table_age</a> set to zero. (You can use the vacuum cost delay parameters described in <a class="xref" href="runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-VACUUM-COST" title="19.4.4. Cost-based Vacuum Delay">Section 19.4.4</a> to reduce the performance consequences for concurrent sessions.) You must use <span class="productname">PostgreSQL</span> 9.3.5 or later to perform this step. </p></li></ol></div><p> </p></li><li class="listitem"><p> Fix rare failure to invalidate relation cache init file (Tom Lane) </p><p> With just the wrong timing of concurrent activity, a <code class="command">VACUUM FULL</code> on a system catalog might fail to update the <span class="quote">“<span class="quote">init file</span>”</span> that's used to avoid cache-loading work for new sessions. This would result in later sessions being unable to access that catalog at all. This is a very ancient bug, but it's so hard to trigger that no reproducible case had been seen until recently. </p></li><li class="listitem"><p> Avoid deadlock between incoming sessions and <code class="literal">CREATE/DROP DATABASE</code> (Tom Lane) </p><p> A new session starting in a database that is the target of a <code class="command">DROP DATABASE</code> command, or is the template for a <code class="command">CREATE DATABASE</code> command, could cause the command to wait for five seconds and then fail, even if the new session would have exited before that. </p></li><li class="listitem"><p> Improve planner's cost estimates for semi-joins and anti-joins with inner indexscans (Tom Lane, Tomas Vondra) </p><p> This type of plan is quite cheap when all the join clauses are used as index scan conditions, even if the inner scan would nominally fetch many rows, because the executor will stop after obtaining one row. The planner only partially accounted for that effect, and would therefore overestimate the cost, leading it to possibly choose some other much less efficient plan type. </p></li></ul></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="release-9-3-10.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="release.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="release-9-3-8.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">E.74. Release 9.3.10 </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> E.76. Release 9.3.8</td></tr></table></div></body></html>