| From: | Joel Jacobson <joel(at)trustly(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Satyanarayana Narlapuram <Satyanarayana(dot)Narlapuram(at)microsoft(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Optional message to user when terminating/cancelling backend |
| Date: | 2017-06-26 14:15:39 |
| Message-ID: | CAASwCXcOwm=ObZ19O2Y8XAeuZWr8Sn0_u1+-V6BRgac90tJk4A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
+1
On Tue, Jun 20, 2017 at 8:54 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> Unless you have a lot of users running psql manually, I don't see how
> this is actually very useful or actionable. What would the user do with
> the information? Hopefully your users already trust that you'd keep the
> downtime to the minimum possible.
I think this feature would be useful for PgTerminator
(https://github.com/trustly/pgterminator)
a tool which automatically kills unprotected processes that could
potentially be the reason why
>X number of protected important processes have been waiting for >Y seconds.
When I'm guilty of locking this in the production DB and get killed by
PgTerminator,
it would be nice to know the reason, e.g. that it was PgTerminator
that killed me
and what process I was blocking.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2017-06-26 14:36:15 | Re: intermittent failures in Cygwin from select_parallel tests |
| Previous Message | Andrew Dunstan | 2017-06-26 14:05:03 | Re: intermittent failures in Cygwin from select_parallel tests |