Thread: 2021-02-11 release announcement draft
Hi, Attached is a draft of the release announcement for the upcoming 2021-02-11 cumulative update release. Please review for technical accuracy (I did screen for typos, but would not be surprised if any slipped in). Please provide feedback on this thread no later than 2020-02-10 AoE[1]. Thanks! Jonathan [1] https://en.wikipedia.org/wiki/Anywhere_on_Earth
Attachment
On Mon, Feb 08, 2021 at 05:40:41PM -0500, Jonathan S. Katz wrote: > This update also fixes over 80 bugs that were reported in the last several > months. Some of these issues only affect version 13, but may also apply to other > supported versions. Did you want s/may/many/? > * Fix an issue with GiST indexes where concurrent insertions could lead to a > corrupt index with entries placed in the wrong pages. You should `REINDEX` any > affected GiST indexes. For what it's worth, there's little way for a user to confirm whether an index is affected. (If you've never had more than one connection changing the table at a time, the table's indexes would be unaffected.) > * Fix `CREATE INDEX CONCURRENTLY` to ensure rows from concurrent prepared > transactions are included in the index. Consider adding a sentence like "Installations that have enabled prepared transactions should `REINDEX` any concurrently-built indexes." The release notes say: + In installations that have enabled prepared transactions + (<varname>max_prepared_transactions</varname> > 0), + it's recommended to reindex any concurrently-built indexes in + case this problem occurred when they were built. > * Fix a failure when a PL/pgSQL procedure used `CALL` on another procedure that > has `OUT` parameters did not call execute a `COMMIT` or `ROLLBACK`. The release notes say the failure happened when the callee _did_ execute a COMMIT or ROLLBACK: + <para> + A <command>CALL</command> in a PL/pgSQL procedure, to another + procedure that has OUT parameters, would fail if the called + procedure did a <command>COMMIT</command> + or <command>ROLLBACK</command>. + </para> > For more details, please see the > [release notes](https://www.postgresql.org/docs/current/release.html). I recommend pointing this to https://www.postgresql.org/docs/release/, since the above link now contains only v13 notes.
> On 02/08/2021 11:40 PM Jonathan S. Katz <jkatz@postgresql.org> wrote: > > > Hi, > > Attached is a draft of the release announcement for the upcoming > 2021-02-11 cumulative update release. Please review for technical 'closes fixes' maybe better is: 'includes fixes' or 'closes bugs' 'also fixes over 80 bugs' Maybe drop the 'also'; those same 80 bugs have just been mentioned. Erik Rijkers
On 2/8/21 11:30 PM, er@xs4all.nl wrote: >> On 02/08/2021 11:40 PM Jonathan S. Katz <jkatz@postgresql.org> wrote: >> >> >> Hi, >> >> Attached is a draft of the release announcement for the upcoming >> 2021-02-11 cumulative update release. Please review for technical > > 'closes fixes' maybe better is: > 'includes fixes' or 'closes bugs' > > > 'also fixes over 80 bugs' > Maybe drop the 'also'; those same 80 bugs have just been mentioned. Thanks for the suggestions. I have included them in the updated draft which I am posting to Noah's reply. Jonathan
Attachment
On 2/8/21 6:11 PM, Noah Misch wrote: > On Mon, Feb 08, 2021 at 05:40:41PM -0500, Jonathan S. Katz wrote: >> This update also fixes over 80 bugs that were reported in the last several >> months. Some of these issues only affect version 13, but may also apply to other >> supported versions. > > Did you want s/may/many/? Nope. The bugs may also apply to other versions. Maybe to be clearer I'll /may/could/? I made that change. > >> * Fix an issue with GiST indexes where concurrent insertions could lead to a >> corrupt index with entries placed in the wrong pages. You should `REINDEX` any >> affected GiST indexes. > > For what it's worth, there's little way for a user to confirm whether an index > is affected. (If you've never had more than one connection changing the table > at a time, the table's indexes would be unaffected.) So Peter Geoghegan and I had a roughly 30 minute back and forth just on this point. Based on our discussion, we felt it best to go with this statement. I think this one is tough to give guidance around, but I don't think a blanket "anyone who has had concurrent writes to a GiST index should reindex" is the right answer. >> * Fix `CREATE INDEX CONCURRENTLY` to ensure rows from concurrent prepared >> transactions are included in the index. > > Consider adding a sentence like "Installations that have enabled prepared > transactions should `REINDEX` any concurrently-built indexes." The release > notes say: > > + In installations that have enabled prepared transactions > + (<varname>max_prepared_transactions</varname> > 0), > + it's recommended to reindex any concurrently-built indexes in > + case this problem occurred when they were built. Oops, I must have missed that in my first build of the release notes (or I just plain missed it). I agree with that. >> * Fix a failure when a PL/pgSQL procedure used `CALL` on another procedure that >> has `OUT` parameters did not call execute a `COMMIT` or `ROLLBACK`. > > The release notes say the failure happened when the callee _did_ execute a > COMMIT or ROLLBACK: > > + <para> > + A <command>CALL</command> in a PL/pgSQL procedure, to another > + procedure that has OUT parameters, would fail if the called > + procedure did a <command>COMMIT</command> > + or <command>ROLLBACK</command>. > + </para> Oops, good catch. Fixed. >> For more details, please see the >> [release notes](https://www.postgresql.org/docs/current/release.html). > > I recommend pointing this to https://www.postgresql.org/docs/release/, since > the above link now contains only v13 notes. WFM. Please see updated draft. Thanks, Jonathan
Attachment
On 02/10/21 10:15, Jonathan S. Katz wrote: > On 2/8/21 6:11 PM, Noah Misch wrote: >> On Mon, Feb 08, 2021 at 05:40:41PM -0500, Jonathan S. Katz wrote: >>> Some of these issues only affect version 13, but may also apply to other >>> supported versions. >> >> Did you want s/may/many/? > > Nope. The bugs may also apply to other versions. Maybe to be clearer > I'll /may/could/? If that's what was intended, shouldn't it be "but others may also apply to other supported versions"? ^^^^^^ Surely the ones that "only affect version 13" do not affect other versions, not even on a 'may' or 'could' basis. Regards, -Chap
Hi, On Wed, Feb 10, 2021 at 10:15:12AM -0500, Jonathan S. Katz wrote: > Please see updated draft. What about the CVEs, it's my understanding that two security issues have been fixed; shouldn't they be mentioned as well? Or are those scheduled to be merged into the announcement at the last minute? Michael -- Michael Banck Projektleiter / Senior Berater Tel.: +49 2166 9901-171 Fax: +49 2166 9901-100 Email: michael.banck@credativ.de credativ GmbH, HRB Mönchengladbach 12080 USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer Unser Umgang mit personenbezogenen Daten unterliegt folgenden Bestimmungen: https://www.credativ.de/datenschutz
On 2/10/21 10:19 AM, Chapman Flack wrote: > On 02/10/21 10:15, Jonathan S. Katz wrote: >> On 2/8/21 6:11 PM, Noah Misch wrote: >>> On Mon, Feb 08, 2021 at 05:40:41PM -0500, Jonathan S. Katz wrote: >>>> Some of these issues only affect version 13, but may also apply to other >>>> supported versions. >>> >>> Did you want s/may/many/? >> >> Nope. The bugs may also apply to other versions. Maybe to be clearer >> I'll /may/could/? > > If that's what was intended, shouldn't it be "but others may also apply > to other supported versions"? ^^^^^^ > > Surely the ones that "only affect version 13" do not affect other versions, > not even on a 'may' or 'could' basis. The main goals of the release announcement are to: * Let people know there are update releases for supported versions that fix bugs. * Provide a glimpse at what is fixed so the reader can determine their level of urgency around updating. * Direct people on where to download and find out more specifics about the releases. I appreciate the suggestions on this sentence, but I don't think the desired goals hinges on this one word. Thanks, Jonathan
Attachment
On Wed, Feb 10, 2021 at 4:36 PM Michael Banck <michael.banck@credativ.de> wrote: > > Hi, > > On Wed, Feb 10, 2021 at 10:15:12AM -0500, Jonathan S. Katz wrote: > > Please see updated draft. > > What about the CVEs, it's my understanding that two security issues have > been fixed; shouldn't they be mentioned as well? Or are those scheduled > to be merged into the announcement at the last minute? Any potential security announcements are handled independently "out of band". -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/