Thread: Press Release Draft - 2016-10-27 Cumulative Update

<div class="">Hello,</div><div class=""><br class="" /></div><div class="">Below is the draft of the press release for
theupdate this Thursday:</div><div class=""><br class="" /></div><div class=""><a class=""
href="https://git.postgresql.org/gitweb/?p=press.git;a=blob;f=update_releases/current/update_201610.md;h=aac4d0b36f3f3017d319ac617eff901efe0c10c0;hb=880dc99766ee0e608e95d9c0f36ce3cde59f470f">https://git.postgresql.org/gitweb/?p=press.git;a=blob;f=update_releases/current/update_201610.md;h=aac4d0b36f3f3017d319ac617eff901efe0c10c0;hb=880dc99766ee0e608e95d9c0f36ce3cde59f470f</a></div><div
class=""><brclass="" /></div><div class="">Per the draft of the release notes, I chose to expand on the data corruption
issuesafter the release summary.  I did include the DISTINCT aggregate crashes at the top of the list of fixes but do
youthink those should be highlighted too?</div><div class=""><br class="" /></div><div class="">If you have feedback,
pleaseleave it within the next 24 hours (following timeline here: <a class=""
href="https://wiki.postgresql.org/wiki/UpdateReleaseDrafting#Tuesday_Night_or_Wednesday_Morning_.28US_Time.29">https://wiki.postgresql.org/wiki/UpdateReleaseDrafting#Tuesday_Night_or_Wednesday_Morning_.28US_Time.29</a>)
soI can incorporate it prior to release.</div><div class=""><br class="" /></div><div class="">Thanks!</div><div
class=""><brclass="" /></div><div class="">Jonathan</div> 

On Mon, Oct 24, 2016 at 1:14 PM, Jonathan Katz
<jonathan.katz@excoventures.com> wrote:
> Hello,
>
> Below is the draft of the press release for the update this Thursday:
>
>
https://git.postgresql.org/gitweb/?p=press.git;a=blob;f=update_releases/current/update_201610.md;h=aac4d0b36f3f3017d319ac617eff901efe0c10c0;hb=880dc99766ee0e608e95d9c0f36ce3cde59f470f

The discussion of truncating the visibility map is repeated twice,
once at the top under "pg_upgrade issues on big-endian machines" and
again at the bottom under "Updating".  We should only have it there
once.  Also, the SQL we're proposing should actually be tested by
someone before posting it - pg_truncate_visibility_map() takes a
mandatory argument, so calling it with no arguments will not work.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Jonathan Katz <jonathan.katz@excoventures.com> writes:
> Below is the draft of the press release for the update this Thursday:

>
https://git.postgresql.org/gitweb/?p=press.git;a=blob;f=update_releases/current/update_201610.md;h=aac4d0b36f3f3017d319ac617eff901efe0c10c0;hb=880dc99766ee0e608e95d9c0f36ce3cde59f470f
<https://git.postgresql.org/gitweb/?p=press.git;a=blob;f=update_releases/current/update_201610.md;h=aac4d0b36f3f3017d319ac617eff901efe0c10c0;hb=880dc99766ee0e608e95d9c0f36ce3cde59f470f>

Couple thoughts:

* I don't believe that the FSM truncation issue is specific to being "in
recovery".  The corruption itself would happen during crash/restart on
a master, or while a standby is following a WAL stream, but the effects
would be seen later.  Suggest just taking out "in recovery" from the
description.

* Please clarify that the pg_upgrade VM issue is only in 9.6.0.

* The recipe for recovery from the VM issue is oversimplified.
Rather than trying to explain how to fix it here, I'd suggest
pointing to the wiki page we've created about that,
https://wiki.postgresql.org/wiki/Visibility_Map_Problems

Looks good to me otherwise.
        regards, tom lane

> On Oct 24, 2016, at 2:49 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Mon, Oct 24, 2016 at 1:14 PM, Jonathan Katz
> <jonathan.katz@excoventures.com> wrote:
>> Hello,
>>
>> Below is the draft of the press release for the update this Thursday:
>>
>>
https://git.postgresql.org/gitweb/?p=press.git;a=blob;f=update_releases/current/update_201610.md;h=aac4d0b36f3f3017d319ac617eff901efe0c10c0;hb=880dc99766ee0e608e95d9c0f36ce3cde59f470f
>
> The discussion of truncating the visibility map is repeated twice,
> once at the top under "pg_upgrade issues on big-endian machines" and
> again at the bottom under "Updating".  We should only have it there
> once.  Also, the SQL we're proposing should actually be tested by
> someone before posting it - pg_truncate_visibility_map() takes a
> mandatory argument, so calling it with no arguments will not work.

I thought it might be good to repeat those instructions so people are clear that there is an actionable step post
upgrade. I’m happy to leave it in just the update section, but make a reference to say “Please see the “Update” section
forpost-install steps.” 

Jonathan