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

  1. Refactor user-facing SQL functions signalling backends

  2. Introduce 64-bit hash functions with a 64-bit seed.