Agree with David on the general usefulness of this channel. Not that Azure has this implementation or proposal today,
butas a managed service this channel of communication is worth. For example, DBA / service can set a policy that if
certainsession exceeds the resource usage DBA can kill it and communicate the same. For example, too many locks, lot of
IOactivity, 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.g.johnston@gmail.com]
Sent: Tuesday, June 20, 2017 12:44 PM
To: 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>
Subject: Re: [HACKERS] Optional message to user when terminating/cancelling backend
On Tue, Jun 20, 2017 at 11:54 AM, Alvaro Herrera <alvherre@2ndquadrant.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
auseful message to communicate; to user or application. Sure, some of this can, and maybe would also need to, be done
out-of-bandbut this communication channel seems worthy enough to at least evaluate the provided implementation.
David J.