On Tue, May 12, 2020 at 6:11 AM Justin Pryzby <pryzby@telsasoft.com> wrote:
>
> On Mon, May 11, 2020 at 10:52:41AM +0530, Amit Kapila wrote:
> > > 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'm not opposed to including it, but I think it's still true that the user
> doesn't need to know in advance that the error message will be additionally
> helpful in the event of corruption. If we were to include more "error" items,
> we might also include these:
>
> 71a8a4f6e36547bb060dbcc961ea9b57420f7190 Add backtrace support for error reporting
> 17a28b03645e27d73bf69a95d7569b61e58f06eb Improve the internal implementation of ereport().
> 05f18c6b6b6e4b44302ee20a042cedc664532aa2 Added relation name in error messages for constraint checks.
> 33753ac9d7bc83dd9ccee9d5e678ed78a0725b4e Add object names to partition integrity violations.
>
I think the first one (Add backtrace support for error reporting)
seems to be quite useful as it can help to detect the problems faster.
I think having a simple rule as Bruce has w.r.t "error messages" makes
it easier to decide whether to take a particular commit or not but I
feel some of these could help users to know the new functionality and
might encourage them to upgrade to the new version. Sure, nobody is
going to move due to only these features but along with other things,
improved error handling is a good thing to know.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com