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.
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 |