Press Release Draft - 2016-10-27 Cumulative Update
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 <https://git.postgresql.org/gitweb/?p=press.git;a=blob;f=update_releases/current/update_201610.md;h=aac4d0b36f3f3017d319ac617eff901efe0c10c0;hb=880dc99766ee0e608e95d9c0f36ce3cde59f470f>
Per the draft of the release notes, I chose to expand on the data corruption issues after the release summary. I did include the DISTINCT aggregate crashes at the top of the list of fixes but do you think those should be highlighted too?
If you have feedback, please leave it within the next 24 hours (following timeline here: 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>) so I can incorporate it prior to release.
Thanks!
Jonathan
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:
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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:
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 for post-install steps.”
Jonathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Oct 24, 2016, at 2:59 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
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_ProblemsLooks good to me otherwise.
Incorporated feedback: https://git.postgresql.org/gitweb/?p=press.git;a=blob;f=update_releases/current/update_201610.md;h=11c9fb9504add6b5c060763722aba1cd2eb4afd4;hb=387f3e441666ce4d2a1e5f4e52247ce3a83e733d <https://git.postgresql.org/gitweb/?p=press.git;a=blob;f=update_releases/current/update_201610.md;h=11c9fb9504add6b5c060763722aba1cd2eb4afd4;hb=387f3e441666ce4d2a1e5f4e52247ce3a83e733d>
Thanks!
Jonathan