Re: Unclear problem reports - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Unclear problem reports
Date
Msg-id 20220205051709.5wpce5jj6g36xb4j@jrouhaud
Whole thread Raw
In response to Re: Unclear problem reports  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Fri, Feb 04, 2022 at 01:38:14PM -0500, Bruce Momjian wrote:
> On Thu, Feb  3, 2022 at 12:28:05PM +0800, Julien Rouhaud wrote:
> 
> > One thing that might help would be to work on a troubleshooting section on the
> > wiki with some common problems and some clear instructions on either how to try
> > to fix the problem or provide needed information for further debugging.  At
> > least it would save the time for those steps and one could quickly respond with
> > that link, similarly to how we do for the slow query questions wiki entry.
> 
> I think the challenge there is that the problems are all different, and
> if we had a pattern we could at least supply better errors and hints,
> unless I am missing something obvious.  Does someone want to go back
> through the bugs@ archive and see if they can find a pattern?

Yes we definitely don't want to have a massive page for every single problem,
but there are probably so really frequent reports for which we can't really
improve the error, and for which we tend to ask the same questions every time
which could benefit from that.

For instance for index corruption, we can suggest using enable_* and checking
the query again to highlight a problem with the index, and hint about system
collation library upgrade and so on.  I probably answered a few reports about
this over the last couple of months, and other also did.

Some immediate errors when trying to start the instance could also be covered
(like the no valid checkpoint record problem), at least to warn to *not* use
pg_resetwal.



pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: Deparsing rewritten query
Next
From: Michael Banck
Date:
Subject: Re: Release notes for February minor releases