Re: Optional message to user when terminating/cancelling backend

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(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-20 19:43:39
Message-ID: CAKFQuwYTiBuxWjhYiiRgve79fX8fh5wgx=jY-=w=5c+0t9dvEQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Satyanarayana Narlapuram 2017-06-20 19:49:59 Re: Optional message to user when terminating/cancelling backend
Previous Message David G. Johnston 2017-06-20 19:34:13 Re: postgresql transactons not fully isolated