Thread: Unclear problem reports
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.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
On Wed, Feb 2, 2022 at 5:35 PM Bruce Momjian <bruce@momjian.us> wrote:
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.
Have pg_lister queue up a check for, say, two or three days after the bug reporting form is filled out. If the report hasn't been responded to by someone other than the OP send out a reply that basically says:
We're sorry your message hasn't yet attracted a response. If your report falls into the category of "tech support for a malfunctioning server", and this includes error messages that are difficult or impossible to replicate in a development environment (maybe give some examples), you may wish to consider eliciting paid professional help. Please see this page on our website for a directory of companies that provide such services. The PostgreSQL Core Project itself refrains from making recommendations since many, if not all, of these companies contribute back to the project in order to keep it both free and open source.
I would also consider adding a form that directs messages to pg_admin instead of pg_bugs. On that form we could put the above message upfront - basically saying that here is a place to ask for help but the core project (this website) doesn't directly provide such services: so if you don't receive a reply, or your needs are immediate, consider enlisting a paid support from our directory.
The problem with the separate form is that we would need users to self-select to report their problem to the support list instead of using a bug reporting form. Neither of the mentioned emails are good examples of bug reports. Either we make it easier and hope self-selection works, or just resign ourselves to seeing these messages on -bugs and use the first option to at least be a bit more responsive. The risks related to having a rote response, namely it not really being applicable to the situation, seem minimal and others seeing that response (assuming we'd send it to the list and not just the OP) would likely encourage someone to at least give better suggestions for next steps should that be necessary.
David J.
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.
On Wed, Feb 2, 2022 at 07:21:19PM -0700, David G. Johnston wrote: > On Wed, Feb 2, 2022 at 5:35 PM Bruce Momjian <bruce@momjian.us> wrote: > > 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. > > > > Have pg_lister queue up a check for, say, two or three days after the bug > reporting form is filled out. If the report hasn't been responded to by > someone other than the OP send out a reply that basically says: > > We're sorry your message hasn't yet attracted a response. If your report falls > into the category of "tech support for a malfunctioning server", and this > includes error messages that are difficult or impossible to replicate in a > development environment (maybe give some examples), you may wish to consider > eliciting paid professional help. Please see this page on our website for a > directory of companies that provide such services. The PostgreSQL Core Project > itself refrains from making recommendations since many, if not all, of these > companies contribute back to the project in order to keep it both free and open > source. Yes, that is an idea. I have canned email responses for common issues like PGAdmin questions on the bugs list, but for these cases, I don't know if someone might actually know the answer, and I don't know how long to wait for an answer. Should we be going the other way and state on the bugs submission page, https://www.postgresql.org/account/submitbug/: If you are having a serious problem with the software and do not receive a reply, consider additional support channels, including professional support (https://www.postgresql.org/support/). I have been hesitant to recommend professional support myself since I work for a professional support company, but in these cases it is clearly something the user should consider. > I would also consider adding a form that directs messages to pg_admin instead > of pg_bugs. On that form we could put the above message upfront - basically > saying that here is a place to ask for help but the core project (this website) > doesn't directly provide such services: so if you don't receive a reply, or > your needs are immediate, consider enlisting a paid support from our directory. Yes, like I stated above. Not sure how pg_admin fits in here because we gets lots of questions that aren't "server not starting". > The problem with the separate form is that we would need users to self-select > to report their problem to the support list instead of using a bug reporting > form. Neither of the mentioned emails are good examples of bug reports. Yes, given the experience of many of the bugs posters, I don't think self-selecting would help. > Either we make it easier and hope self-selection works, or just resign > ourselves to seeing these messages on -bugs and use the first option to at > least be a bit more responsive. The risks related to having a rote response, > namely it not really being applicable to the situation, seem minimal and others > seeing that response (assuming we'd send it to the list and not just the OP) > would likely encourage someone to at least give better suggestions for next > steps should that be necessary. The problem is that I don't even know how long to wait for someone to reply, so doing it up front makes more sense. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.
On Thu, Feb 3, 2022 at 12:28:05PM +0800, Julien Rouhaud wrote: > 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. Agreed. > 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? -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.
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.
On Fri, Feb 04, 2022 at 01:36:46PM -0500, Bruce Momjian wrote: > On Wed, Feb 2, 2022 at 07:21:19PM -0700, David G. Johnston wrote: > > On Wed, Feb 2, 2022 at 5:35 PM Bruce Momjian <bruce@momjian.us> wrote: > > Have pg_lister queue up a check for, say, two or three days after the bug > > reporting form is filled out. If the report hasn't been responded to by > > someone other than the OP send out a reply that basically says: > > > > We're sorry your message hasn't yet attracted a response. If your report falls > > into the category of "tech support for a malfunctioning server", and this > > includes error messages that are difficult or impossible to replicate in a > > development environment (maybe give some examples), you may wish to consider > > eliciting paid professional help. Please see this page on our website for a > > directory of companies that provide such services. The PostgreSQL Core Project > > itself refrains from making recommendations since many, if not all, of these > > companies contribute back to the project in order to keep it both free and open > > source. > > Yes, that is an idea. I have canned email responses for common issues > like PGAdmin questions on the bugs list, but for these cases, I don't > know if someone might actually know the answer, and I don't know how > long to wait for an answer. Should we be going the other way and state > on the bugs submission page, https://www.postgresql.org/account/submitbug/: > > If you are having a serious problem with the software and do not > receive a reply, consider additional support channels, including > professional support (https://www.postgresql.org/support/). https://www.postgresql.org/account/submitbug/ does say to "ensure you have read" https://www.postgresql.org/docs/current/bug-reporting.html, which says, "If you need help immediately, consider obtaining a commercial support contract." Hence, this expands on an existing message and makes it more prominent. I think that's reasonable, though I'm not sure it's a net win. One could also edit the page that appears after submitting a bug. Editing a web page is superior to using canned email responses, for two reasons: - Canned responses are noise to every list reader other than the OP. - Canned responses make the list feel like a sales funnel rather than a normal free software mailing list. It's safe to say $SUBJECT won't have a general solution. There will always be some vanguard of tough user experiences, each one implying a separate project. For example, Julien replied to the "could not locate a valid checkpoint record" -bugs thread with some followup questions, but one could improve the log messages to answer those questions. Where we don't know how to improve the product enough, wiki pages (Julien suggested this) seem good.
Hi, On 2022-02-02 19:35:36 -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? I think some of this can be improved measurably, with moderate effort, by improving our error messages / diagnostics. Taking e.g. the second report: [7804] LOG: starting PostgreSQL 13.1, compiled by Visual C++ build 1914, 64-bit [8812] LOG: invalid primary checkpoint record [8812] PANIC: could not locate a valid checkpoint record [7804] LOG: startup process (PID 8812) was terminated by exception 0xC0000409 [7804] HINT: See C include file "ntstatus.h" for a description of the hexadecimal value. [7804] LOG: aborting startup due to startup process failure [7804] LOG: database system is shut down We don't provide any details in this log report that allow to diagnose the problem: "invalid primary checkpoint record" doesn't say *why* it's invalid, nor does it say the location at which the checkpoint record was, nor whether the cluster was shutdown gracefully before. It could be that the permissions on the WAL files were wrong, it could be missing files, actually invalid WAL, ... The while following bit about "startup process ... was terminated" and it's HINT is useless information, because we actually "knowingly" caused that PANIC. Even disregarding that, it certainly doesn't help to list numerical exception codes and references to ntstatus.h. The first report is similar, although it's a bit harder to improve: ERROR: missing chunk number 0 for toast value 152073604 in pg_toast_2619 Easy to fix: We don't mention the table that pg_toast_2619 corresponds to - something we can determine, rather forcing the user to figure out how to do so. Harder to fix: We don't provide information about where the reference to the toast value comes from. In general we don't necessarily know that, because Datum's are handed around fairly widely. But in a lot of cases we actually could know. > 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. I think these are more our fault than our users :( Greetings, Andres Freund
On Sun, Feb 6, 2022 at 12:02 AM Noah Misch <noah@leadboat.com> wrote: > > On Fri, Feb 04, 2022 at 01:36:46PM -0500, Bruce Momjian wrote: > > On Wed, Feb 2, 2022 at 07:21:19PM -0700, David G. Johnston wrote: > > > On Wed, Feb 2, 2022 at 5:35 PM Bruce Momjian <bruce@momjian.us> wrote: > > > Have pg_lister queue up a check for, say, two or three days after the bug > > > reporting form is filled out. If the report hasn't been responded to by > > > someone other than the OP send out a reply that basically says: > > > > > > We're sorry your message hasn't yet attracted a response. If your report falls > > > into the category of "tech support for a malfunctioning server", and this > > > includes error messages that are difficult or impossible to replicate in a > > > development environment (maybe give some examples), you may wish to consider > > > eliciting paid professional help. Please see this page on our website for a > > > directory of companies that provide such services. The PostgreSQL Core Project > > > itself refrains from making recommendations since many, if not all, of these > > > companies contribute back to the project in order to keep it both free and open > > > source. > > > > Yes, that is an idea. I have canned email responses for common issues > > like PGAdmin questions on the bugs list, but for these cases, I don't > > know if someone might actually know the answer, and I don't know how > > long to wait for an answer. Should we be going the other way and state > > on the bugs submission page, https://www.postgresql.org/account/submitbug/: > > > > If you are having a serious problem with the software and do not > > receive a reply, consider additional support channels, including > > professional support (https://www.postgresql.org/support/). > > https://www.postgresql.org/account/submitbug/ does say to "ensure you have > read" https://www.postgresql.org/docs/current/bug-reporting.html, which says, > "If you need help immediately, consider obtaining a commercial support > contract." Hence, this expands on an existing message and makes it more > prominent. I think that's reasonable, though I'm not sure it's a net win. > One could also edit the page that appears after submitting a bug. Editing a > web page is superior to using canned email responses, for two reasons: > > - Canned responses are noise to every list reader other than the OP. > - Canned responses make the list feel like a sales funnel rather than a normal > free software mailing list. All bug reports posted through the bug form gets moderated before they're passed through. Moderators also have access to a set of pre-defined canned responses (such as the example of where they should go to report pgadmin bugs). It will also catch posts made directly to -bugs by people who are not subscribed, but people who are subscribed will not have their posts moderated by default. If we're talking about people submitting bug reports, åperhaps a lot can be done with (1) a couple of more such responses and (2) more clear instructions fo the moderators of when they are supposed to use them. Error on the side of letting them through is probably always the best choice, but if it's clear that it can be better handled by a canned response, we do have an actual system for that. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
On Sun, Feb 06, 2022 at 12:41:52AM +0100, Magnus Hagander wrote: > On Sun, Feb 6, 2022 at 12:02 AM Noah Misch <noah@leadboat.com> wrote: > > On Fri, Feb 04, 2022 at 01:36:46PM -0500, Bruce Momjian wrote: > > > On Wed, Feb 2, 2022 at 07:21:19PM -0700, David G. Johnston wrote: > > > > Have pg_lister queue up a check for, say, two or three days after the bug > > > > reporting form is filled out. If the report hasn't been responded to by > > > > someone other than the OP send out a reply that basically says: > > > > > > > > We're sorry your message hasn't yet attracted a response. If your report falls > > > > into the category of "tech support for a malfunctioning server", and this > > > > includes error messages that are difficult or impossible to replicate in a > > > > development environment (maybe give some examples), you may wish to consider > > > > eliciting paid professional help. Please see this page on our website for a > > > > directory of companies that provide such services. The PostgreSQL Core Project > > > > itself refrains from making recommendations since many, if not all, of these > > > > companies contribute back to the project in order to keep it both free and open > > > > source. > > > > > > Yes, that is an idea. I have canned email responses for common issues > > > like PGAdmin questions on the bugs list, but for these cases, I don't > > > know if someone might actually know the answer, and I don't know how > > > long to wait for an answer. Should we be going the other way and state > > > on the bugs submission page, https://www.postgresql.org/account/submitbug/: > > > > > > If you are having a serious problem with the software and do not > > > receive a reply, consider additional support channels, including > > > professional support (https://www.postgresql.org/support/). > > > > https://www.postgresql.org/account/submitbug/ does say to "ensure you have > > read" https://www.postgresql.org/docs/current/bug-reporting.html, which says, > > "If you need help immediately, consider obtaining a commercial support > > contract." Hence, this expands on an existing message and makes it more > > prominent. I think that's reasonable, though I'm not sure it's a net win. > > One could also edit the page that appears after submitting a bug. Editing a > > web page is superior to using canned email responses, for two reasons: > > > > - Canned responses are noise to every list reader other than the OP. > > - Canned responses make the list feel like a sales funnel rather than a normal > > free software mailing list. > > All bug reports posted through the bug form gets moderated before > they're passed through. Moderators also have access to a set of > pre-defined canned responses (such as the example of where they should > go to report pgadmin bugs). It will also catch posts made directly to > -bugs by people who are not subscribed, but people who are subscribed > will not have their posts moderated by default. > > If we're talking about people submitting bug reports, åperhaps a lot > can be done with (1) a couple of more such responses and (2) more > clear instructions fo the moderators of when they are supposed to use > them. > > Error on the side of letting them through is probably always the best > choice, but if it's clear that it can be better handled by a canned > response, we do have an actual system for that. I was referring to David G. Johnston's proposal to send canned email responses when a thread (presumably containing a not-obviously-unreasonable PostgreSQL question or report) gets no replies in N days. The proposed email directed the user toward paid professional services. Sending such a message at moderation time would solve the noise problem, but it would make the "sales funnel" problem worse. (Also, I figure moderators won't know at moderation time which messages will get zero replies.) For which part of $SUBJECT did you envision using new moderator responses?
On Sun, Feb 6, 2022 at 5:28 AM Noah Misch <noah@leadboat.com> wrote: > > > > - Canned responses are noise to every list reader other than the OP. > > > - Canned responses make the list feel like a sales funnel rather than a normal > > > free software mailing list. > > > > All bug reports posted through the bug form gets moderated before > > they're passed through. Moderators also have access to a set of > > pre-defined canned responses (such as the example of where they should > > go to report pgadmin bugs). It will also catch posts made directly to > > -bugs by people who are not subscribed, but people who are subscribed > > will not have their posts moderated by default. > > > > If we're talking about people submitting bug reports, åperhaps a lot > > can be done with (1) a couple of more such responses and (2) more > > clear instructions fo the moderators of when they are supposed to use > > them. > > > > Error on the side of letting them through is probably always the best > > choice, but if it's clear that it can be better handled by a canned > > response, we do have an actual system for that. > > I was referring to David G. Johnston's proposal to send canned email responses > when a thread (presumably containing a not-obviously-unreasonable PostgreSQL > question or report) gets no replies in N days. The proposed email directed > the user toward paid professional services. Sending such a message at > moderation time would solve the noise problem, but it would make the "sales > funnel" problem worse. (Also, I figure moderators won't know at moderation > time which messages will get zero replies.) For which part of $SUBJECT did > you envision using new moderator responses? IMO, having a postgresql wiki page describing the steps to debug or perhaps fix the most common problems/bugs is a good idea. Of course, adding the steps to wiki and maintaining it takes some effort from the experts here. But this is better than having canned email responses for bug reports which requires more effort than a wiki page. Today, there are a lot of outside resources listing the steps to fix/debug a postgres related issue. The users can always refer to the wiki page and try out things on their own, if the steps don't fix the issue, they can always reach out via postgresql bugs list. I also agree with the point that improving some of the most common error messages with hints on what to do next to fix the issues. Regards, Bharath Rupireddy.
On Sun, Feb 6, 2022 at 12:58 AM Noah Misch <noah@leadboat.com> wrote: > > On Sun, Feb 06, 2022 at 12:41:52AM +0100, Magnus Hagander wrote: > > On Sun, Feb 6, 2022 at 12:02 AM Noah Misch <noah@leadboat.com> wrote: > > > On Fri, Feb 04, 2022 at 01:36:46PM -0500, Bruce Momjian wrote: > > > > On Wed, Feb 2, 2022 at 07:21:19PM -0700, David G. Johnston wrote: > > > > > Have pg_lister queue up a check for, say, two or three days after the bug > > > > > reporting form is filled out. If the report hasn't been responded to by > > > > > someone other than the OP send out a reply that basically says: > > > > > > > > > > We're sorry your message hasn't yet attracted a response. If your report falls > > > > > into the category of "tech support for a malfunctioning server", and this > > > > > includes error messages that are difficult or impossible to replicate in a > > > > > development environment (maybe give some examples), you may wish to consider > > > > > eliciting paid professional help. Please see this page on our website for a > > > > > directory of companies that provide such services. The PostgreSQL Core Project > > > > > itself refrains from making recommendations since many, if not all, of these > > > > > companies contribute back to the project in order to keep it both free and open > > > > > source. > > > > > > > > Yes, that is an idea. I have canned email responses for common issues > > > > like PGAdmin questions on the bugs list, but for these cases, I don't > > > > know if someone might actually know the answer, and I don't know how > > > > long to wait for an answer. Should we be going the other way and state > > > > on the bugs submission page, https://www.postgresql.org/account/submitbug/: > > > > > > > > If you are having a serious problem with the software and do not > > > > receive a reply, consider additional support channels, including > > > > professional support (https://www.postgresql.org/support/). > > > > > > https://www.postgresql.org/account/submitbug/ does say to "ensure you have > > > read" https://www.postgresql.org/docs/current/bug-reporting.html, which says, > > > "If you need help immediately, consider obtaining a commercial support > > > contract." Hence, this expands on an existing message and makes it more > > > prominent. I think that's reasonable, though I'm not sure it's a net win. > > > One could also edit the page that appears after submitting a bug. Editing a > > > web page is superior to using canned email responses, for two reasons: > > > > > > - Canned responses are noise to every list reader other than the OP. > > > - Canned responses make the list feel like a sales funnel rather than a normal > > > free software mailing list. > > > > All bug reports posted through the bug form gets moderated before > > they're passed through. Moderators also have access to a set of > > pre-defined canned responses (such as the example of where they should > > go to report pgadmin bugs). It will also catch posts made directly to > > -bugs by people who are not subscribed, but people who are subscribed > > will not have their posts moderated by default. > > > > If we're talking about people submitting bug reports, åperhaps a lot > > can be done with (1) a couple of more such responses and (2) more > > clear instructions fo the moderators of when they are supposed to use > > them. > > > > Error on the side of letting them through is probably always the best > > choice, but if it's clear that it can be better handled by a canned > > response, we do have an actual system for that. > > I was referring to David G. Johnston's proposal to send canned email responses > when a thread (presumably containing a not-obviously-unreasonable PostgreSQL > question or report) gets no replies in N days. The proposed email directed > the user toward paid professional services. Sending such a message at > moderation time would solve the noise problem, but it would make the "sales > funnel" problem worse. (Also, I figure moderators won't know at moderation > time which messages will get zero replies.) For which part of $SUBJECT did > you envision using new moderator responses? It depends. For some of them it would, and I believe they are used for that as well. But yes, it will only be able to replace those cases where people send a canned response today ("report pgadmin bugs over here instead", "you need to talk to your cloud vendor" and things like that). It won't help for anything more advanced than that. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/