Re: Optional message to user when terminating/cancelling backend

Agree with David on the general usefulness of this channel. Not that Azure has this implementation or proposal today, but as a managed service this channel of communication is worth. For example, DBA / service can set a policy that if certain session exceeds the resource usage DBA can kill it and communicate the same. For example, too many locks, lot of IO activity, large open transactions etc. The messages will help application developer to tune their workloads appropriately.

Thanks,
Satya

-----Original Message-----
From: David G. Johnston [mailto:david(dot)g(dot)johnston(at)gmail(dot)com]
Sent: Tuesday, June 20, 2017 12:44 PM
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: [HACKERS] Optional message to user when terminating/cancelling backend

On Tue, Jun 20, 2017 at 11:54 AM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> Satyanarayana Narlapuram 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.
>

Why wouldn't this be useful in application logs? Spurious dropped connections during application execution would be alarming. Seeing a message from the DBA when looking into those would be a painless and quick way to alleviate stress.

pg_cancel_backend(<pid>, 'please try not to leave sessions in an "idle in transaction" state...') would also seem like a useful message to communicate; to user or application. Sure, some of this can, and maybe would also need to, be done out-of-band but this communication channel seems worthy enough to at least evaluate the provided implementation.

David J.