Date: Mon, 11 May 2020 20:20:26 -0400
From: Bruce Momjian <bruce@momjian.us>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: PG 13 release notes, first draft
Message-ID: <20200512002026.GI4666@momjian.us>
References: <20200505031600.GB21752@momjian.us>
 <CAA4eK1+tOd6vTXBjUyjEQF+NALdoX8d-EZu5HEs_nxZ-huX2Hw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAA4eK1+tOd6vTXBjUyjEQF+NALdoX8d-EZu5HEs_nxZ-huX2Hw@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On Sat, May  9, 2020 at 11:16:27AM +0530, Amit Kapila wrote:
> On Tue, May 5, 2020 at 8:46 AM Bruce Momjian <bruce@momjian.us> wrote:
> >
> > I have committed the first draft of the PG 13 release notes.  You can
> > see them here:
> >
> >         https://momjian.us/pgsql_docs/release-13.html
> >
> 
> Thanks for the work.  I was today going through the release notes and
> was wondering whether we should consider adding information about some
> other work done for PG13.
> 1.  We have allowed an (auto)vacuum to display additional information
> about heap or index in case of an error in commit b61d161c14 [1].
> Now, in general, it might not be worth saying much about error
> information but I think this one could help users in case they have
> some corruption.  For example, if one of the indexes on a relation has
> some corrupted data (due to bad hardware or some bug), it will let the
> user know the index information, and the user can take appropriate
> action like either Reindex or maybe drop and recreate the index to
> overcome the problem.

I mentioned my approach to error message changes in a previous email
today:

	I skipped that commit since people don't normally care about
	better error messages until they see the error message, and then
	they are happy it is there, unless this is some chronic error
	message problem we are fixing.

> 2. In the "Source Code" section, we can add information about
> infrastructure enhancement for parallelism.  Basically, "Allow
> relation extension and page lock to conflict among parallel-group
> members" [2][3].  This will allow improving the parallelism further in
> many cases like (a) we can allow multiple workers to operate on a heap
> and index in a parallel vacuum, (b) we can allow parallel Inserts,
> etc.

Uh, if there is no user-visible behavior change, this seems too low
level for the release notes.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +