<div><div dir="rtl"><div dir="ltr">Hi,<br><br></div>
<div dir="ltr">What are standbys?</div>
<div dir="ltr">My question was more of how to actualy do the update to a specific versions.</div>
<div dir="ltr">What are the commands to do it? normaly the default upgrade is for the latest version.</div>
<div dir="ltr">I'm not sure what is the recommndation. Should I just update directly to 9.3.16? It's very confusing how to do it somoothly.</div></div><section class="cust_msg_end"></section><blockquote style="margin:0;margin-bottom:20px;border-top:1px solid #e0e0e0;"><br>ב אפר׳ 26, 2017 16:42, Adrian Klaver כתב:<blockquote style="margin:0;margin-bottom:20px;border-top:1px solid #e0e0e0">On 04/26/2017 03:36 AM, Ron Ben wrote:<br>> Hi :)<br>><br>> I do have a test enviroment and I will test eveything there first but I<br>> had cases where eveything worked on test but on production I had<br>> difficultes. It's rare but can happen.<br>> Problems with upgrading PostgreSQL isn't like upgrading a package which<br>> effects few functions.<br>> Since the documntation says just replace the executables I'm lost...<br>> I notced that 9.3.5 and 9.3.9 requires sepcific test. Further more it<br>> says secificly not to perform the tests for 9.3.9 with versions piror to<br>> 9.3.5 as it might not work : "The lingering effects of a<br>> previously-fixed bug in pg_upgrade could also cause such a failure, in<br>> installations that had used pg_upgrade versions between 9.3.0 and<br>> 9.3.4." So this means I have to upgrade to 9.3.5 and only then to 9.3.16<br><br>This only applies if you used the pg_upgrade program to upgrade to a 9.3 <br>cluster. If you used dump/restore it does not apply:<br><br><a href="https://www.postgresql.org/docs/9.3/static/release-9-3-5.html">https://www.postgresql.org/docs/9.3/static/release-9-3-5.html</a><br>"<br>In pg_upgrade, remove pg_multixact files left behind by initdb (Bruce <br>Momjian)<br><br>If you used a pre-9.3.5 version of pg_upgrade to upgrade a database <br>cluster to 9.3, it might have left behind a file <br>PGDATA/pg_multixact/offsets/0000 that should not be there and will <br>eventually cause problems in VACUUM. However, in common cases this file <br>is actually valid and must not be removed. To determine whether your <br>installation has this problem, run this query as superuser, in any <br>database of the cluster:<br><br>WITH list(file) AS (SELECT * FROM pg_ls_dir('pg_multixact/offsets'))<br>SELECT EXISTS (SELECT * FROM list WHERE file = '0000') AND<br> NOT EXISTS (SELECT * FROM list WHERE file = '0001') AND<br> NOT EXISTS (SELECT * FROM list WHERE file = 'FFFF') AND<br> EXISTS (SELECT * FROM list WHERE file != '0000')<br> AS file_0000_removal_required;<br><br>If this query returns t, manually remove the file <br>PGDATA/pg_multixact/offsets/0000. Do nothing if the query returns f.<br>"<br><br>> How do I perform upgrade in steps to specific versions?<br><br>9.3.3 -- > 9.3.4<br><br><a href="https://www.postgresql.org/docs/9.3/static/release-9-3-4.html">https://www.postgresql.org/docs/9.3/static/release-9-3-4.html</a><br><br>"However, the error fixed in the first changelog entry below could have <br>resulted in corrupt data on standby servers. It may be prudent to <br>reinitialize standby servers from fresh base backups after installing <br>this update."<br><br>So if you are not running any standbys a no-op.<br><br>9.3.4 --> 9.3.5<br><br>The above mentioned pg_upgrade bug, so if you did not use pg_upgrade <br>another no-op.<br><br>9.3.5 -- > 9.3.6<br><br><a href="https://www.postgresql.org/docs/9.3/static/release-9-3-6.html">https://www.postgresql.org/docs/9.3/static/release-9-3-6.html</a><br><br>"However, if you are a Windows user and are using the "Norwegian <br>(Bokmål)" locale, manual action is needed after the upgrade to replace <br>any "Norwegian (Bokmål)_Norway" locale names stored in PostgreSQL system <br>catalogs with the plain-ASCII alias "Norwegian_Norway". For details see <br><a href="http://wiki.postgresql.org/wiki/Changes_To_Norwegian_Locale" "="">http://wiki.postgresql.org/wiki/Changes_To_Norwegian_Locale"</a><br><br>So if you are not using the Norwegian local on Windows another no-op.<br><br>9.3.6 -- > 9.3.7<br><br><a href="https://www.postgresql.org/docs/9.3/static/release-9-3-7.html">https://www.postgresql.org/docs/9.3/static/release-9-3-7.html</a><br><br>"However, if you use contrib/citext's regexp_matches() functions, see <br>the changelog entry below about that."<br><br>9.3.7 -- > 9.3.8<br><br><a href="https://www.postgresql.org/docs/9.3/static/release-9-3-8.html">https://www.postgresql.org/docs/9.3/static/release-9-3-8.html</a><br><br>If you have covered the above nothing to do.<br><br>9.3.8 -- > 9.3.9<br><br><a href="https://www.postgresql.org/docs/9.3/static/release-9-3-9.html">https://www.postgresql.org/docs/9.3/static/release-9-3-9.html</a><br><br>"However, if you are upgrading an installation that was previously <br>upgraded using a pg_upgrade version between 9.3.0 and 9.3.4 inclusive, <br>see the first changelog entry below."<br><br>If you did not use pg_upgrade a no-op.<br><br>9.3.9 --> 9.3.14<br><br>All refer you back to the above entry for 9.3.9<br><br>9.3.14 --> 9.3.15<br><br><a href="https://www.postgresql.org/docs/9.3/static/release-9-3-15.html">https://www.postgresql.org/docs/9.3/static/release-9-3-15.html</a><br><br>"However, if your installation has been affected by the bug described in <br>the first changelog entry below, then after updating you may need to <br>take action to repair corrupted free space maps.<br><br><br><br>Fix WAL-logging of truncation of relation free space maps and visibility <br>maps (Pavan Deolasee, Heikki Linnakangas)<br><br>It was possible for these files to not be correctly restored during <br>crash recovery, or to be written incorrectly on a standby server. Bogus <br>entries in a free space map could lead to attempts to access pages that <br>have been truncated away from the relation itself, typically producing <br>errors like "could not read block XXX: read only 0 of 8192 bytes". <br>Checksum failures in the visibility map are also possible, if <br>checksumming is enabled.<br><br>Procedures for determining whether there is a problem and repairing it <br>if so are discussed at <br><a href="https://wiki.postgresql.org/wiki/Free_Space_Map_Problems.">https://wiki.postgresql.org/wiki/Free_Space_Map_Problems.</a><br>"<br><br>9.3.15 --> 9.3.16<br><br><a href="https://www.postgresql.org/docs/9.3/static/release-9-3-16.html">https://www.postgresql.org/docs/9.3/static/release-9-3-16.html</a><br><br>"However, if your installation has been affected by the bug described in <br>the first changelog entry below, then after updating you may need to <br>take action to repair corrupted indexes.<br><br>...<br><br>Fix a race condition that could cause indexes built with CREATE INDEX <br>CONCURRENTLY to be corrupt (Pavan Deolasee, Tom Lane)<br><br>If CREATE INDEX CONCURRENTLY was used to build an index that depends on <br>a column not previously indexed, then rows updated by transactions that <br>ran concurrently with the CREATE INDEX command could have received <br>incorrect index entries. If you suspect this may have happened, the most <br>reliable solution is to rebuild affected indexes after installing this <br>update.<br>"<br><br><br>><br>> I'm runing 9.3.3 in production server and in test server.<br>> Operating system is Ubuntu server 12<br>><br>> I'm still not sure that I can upgrade directly from 9.3.3 to 9.3.16 -<br>> The documntation always tells to "if you are upgrading from version<br>> earlier than 9.3.X check 9.3.X-1". It assums that everyone upgrading<br>> once the version was released which is not always the case. And as<br><br>No it does not, that is why the 'if upgrading form version earlier then <br>version X.X.x' instructions.<br><br>You can upgrade from 9.3.3 --> 9.3.16. If you did not use pg_upgrade and <br>are not using standbys you will not be affected by the early bugs. To <br>verify you run the query in the 9.3.5 release notes. The bugs in the <br>last two entries are going exist in any version before them so you might <br>as well skip over those versions anyway and then check using the <br>instructions in the release notes.<br><br><br>> mentioned earlier 9.3.5 and 9.3.9 can create problems as they require<br>> specific checks.<br>><br>><br>> I'd appriciate any insight.<br>><br>><br>><br>><br>><br>><br>> ב ×פר׳ 26, 2017 13:26, Sameer Kumar כתב:<br>><br>><br>><br>> On Wed, Apr 26, 2017 at 4:41 PM Ron Ben <ronb910(at)walla(dot)co(dot)il<br>> <mailto:ronb910(at)walla(dot)co(dot)il>> wrote:<br>><br>> I'm runing PostgreSQL 9.3.3 and I want to upgrade it to the<br>> latest 9.3 version<br>> The documontation does not specify what needs to be done<br>> other than "just install the executables".<br>> This is wierd as for example 9.3.5 release notes request to<br>> run a specifc query to check for pg_multixact files left.<br>><br>> I saw this question:<br>> <a href="https://serverfault.com/questions/563667/update-9-3-x-minor-verison-of-postgres-on-ubuntu-12-04">https://serverfault.com/questions/563667/update-9-3-x-minor-verison-of-postgres-on-ubuntu-12-04</a><br>> I'm not sure how this will handle the 9.3.5 check issue.<br>><br>><br>><br>><br>> What is the version of PostgreSQL that you are running?<br>><br>> Though there are some general guidelines/procedure (which is as<br>> simple as stop the server, upgrade binaries and start, there<br>> will also be some peculiar releases which has a bug-fix. While<br>> the bug-fix covers you in future, there might have been<br>> incidents where you are already bitten by bug being fixed (worse<br>> if you have not yet identified it). To cover such cases, you<br>> would need to follow some custom procedure. Again, mostly the<br>> custom steps are not for patch application but more of a<br>> mitigation against risks of bug or in some cases bug-fix.<br>><br>> Are you running with a standby or just stand-alone setup?<br>><br>><br>><br>> Is it really just runing one command?<br>> What if there are errors and problems? how do i revert back?<br>> Sadly there is not enough information regarding minor verion<br>> updates...<br>><br>> I'm also runing ubuntu server 12 which will be updated as<br>> well later this quarter.<br>><br>><br>> Do you have a test environment? If I were you I would have a<br>> non-prod that mimics my production setup exactly and I would<br>> apply the patch there first.<br>><br>> --<br>><br>> --<br>><br>> Best Regards,<br>><br>> *Sameer Kumar | Senior Solution Architect*<br>><br>> *ASHNIK PTE. LTD.*<br>><br>> 101 Cecil Street, #11-11 Tong Eng Building, Singapore 069533<br>><br>> T: +65 6438 3504 | www.ashnik.com <<a href="http://www.ashnik.com></a>">http://www.ashnik.com/></a><br>><br>> Skype: sameer.ashnik | M: +65 8110 0350<br>><br><br><br>-- <br>Adrian Klaver<br>adrian(dot)klaver(at)aklaver(dot)com<br><br><br>-- <br>Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)<br>To make changes to your subscription:<br><a href="http://www.postgresql.org/mailpref/pgsql-general">http://www.postgresql.org/mailpref/pgsql-general</a><br><br></mailto:ronb910(at)walla(dot)co(dot)il></ronb910(at)walla(dot)co(dot)il<br><br></blockquote></blockquote><br></div>