Re: Optional message to user when terminating/cancelling backend
Joshua D. Drake <jd@commandprompt.com>
From: "Joshua D. Drake" <jd@commandprompt.com>
To: Joel Jacobson <joel@trustly.com>,
Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Satyanarayana Narlapuram <Satyanarayana.Narlapuram@microsoft.com>,
Pavel Stehule <pavel.stehule@gmail.com>, Daniel Gustafsson
<daniel@yesql.se>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2017-06-26T14:39:00Z
Lists: pgsql-hackers
On 06/26/2017 07:15 AM, Joel Jacobson wrote: > +1 > > On Tue, Jun 20, 2017 at 8:54 PM, Alvaro Herrera > <alvherre@2ndquadrant.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. And not just the pid but literally "what". jD -- Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc PostgreSQL Centered full stack support, consulting and development. Advocate: @amplifypostgres || Learn: https://pgconf.us ***** Unless otherwise stated, opinions are my own. *****
Commits
-
Refactor user-facing SQL functions signalling backends
- 09921f397b84 12.0 landed
-
Introduce 64-bit hash functions with a 64-bit seed.
- 81c5e46c490e 11.0 cited