Re: Unclear problem reports - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Unclear problem reports
Date
Msg-id 20220203042805.sshidsja3m6kjqcj@jrouhaud
Whole thread Raw
In response to Unclear problem reports  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Unclear problem reports
List pgsql-hackers
Hi,

On Wed, Feb 02, 2022 at 07:35:36PM -0500, Bruce Momjian wrote:
> The Postgres community is great at diagnosing problems and giving users
> feedback.  In most cases, we can either diagnose a problem and give a
> fix, or at least give users a hint at finding the cause.
> 
> However, there is a class of problems that are very hard to help with,
> and I have perhaps seen an increasing number of them recently, e.g.:
> 
>     https://www.postgresql.org/message-id/17384-f50f2eedf541e512%40postgresql.org
>     https://www.postgresql.org/message-id/CALTnk7uOrMztNfzjNOZe3TdquAXDPD3vZKjWFWj%3D-Fv-gmROUQ%40mail.gmail.com
> 
> I consider these as problems that need digging to find the cause, and
> users are usually unable to do sufficient digging, and we don't have
> time to give them instructions, so they never get a reply.
> 
> Is there something we can do to improve this situation?  Should we just
> tell them they need to hire a Postgres expert?  I assume these are users
> who do not already have access to such experts.

There's also only so much you can do to help interacting by mail without
access to the machine, even if you're willing to spend time helping people for
free.

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.



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: support for CREATE MODULE
Next
From: Masahiko Sawada
Date:
Subject: Re: Design of pg_stat_subscription_workers vs pgstats