Re: PG 14 release notes, first draft

On Wed, Jun 30, 2021 at 11:20 PM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>
> On Tue, Jun 29, 2021 at 07:36:47PM +0100, Simon Riggs wrote:
> > Perhaps we should also add this text from the commit message to ensure
> > the importance is understood:
> > "This is extremely useful in cases where CIC/RC can run for a very long
> > time, because that used to be a significant headache for concurrent
> > vacuuming of other tables."
>
> Uh, hopefully this idea is captured below.
>
> > Proposed edits:
> >
> > * "during certain index operations" -> "while concurrent index
> > operations run on other tables"
>
> Uh, the problem here is that it isn't clear if we are talking about
> concurrent index operations, "concurrently"-enabled index options, or
> "concurrently"-enabled concurrent index operations. I went with
> "minimal-locking index operations".
>
> > * spell Alvaro's name correctly
>
> Uh, this is the second time Mutt's default to using iso-8859-1 for
> non-ASCII attachments has caused confusion. I found that using 'set
> send_charset="us-ascii:utf-8"' in Mutt fixed this, so the attachment
> should now be fine.
>
> > * "row expiration" is a term not currently used in PG docs, so we
> > should probably look for something else.
>
> Yeah, I changed that to "removing dead rows" which seems to be our
> standard text.

What you have now looks great for this feature, thanks.

> > There are 2 important features here, so the 2nd feature is worth
> > mentioning also:
> >
> > Avoid spurious waits in concurrent indexing
> >
> > Previously, multiple concurrent index operations could deadlock or
> > cause long waits.
> > Waits are avoided except for indexes with expressions, or WHERE predicates.
>
> OK, I added text to the bottom to try and capture that; new patch
> attached, now with UTF8 encoding.

The text from "This also avoids..." tries to explain this, but they
are two separate features, each important in its own right.

So regrettably, this part doesn't capture it, for me.

--
Simon Riggs http://www.EnterpriseDB.com/