Re: proposal: hide application_name from other users

From: Greg Stark <stark(at)mit(dot)edu>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Harold Giménez <harold(at)heroku(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: hide application_name from other users
Date: 2014-01-22 20:28:43
Message-ID: CAM-w4HMOHAjhhBCzQTwMW8Ti7xtppR1-m9Lc0cvEXXRi6FbNJg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 21, 2014 at 7:38 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Harold Giménez (harold(at)heroku(dot)com) wrote:
>> Definitely agree with you. This is just an example of how running
>> monitoring as superuser is not necessarily the worst thing, and there
>> are other reasons to do it already.
>
> It's a horrible thing and that isn't a good reason- if my database isn't
> accepting connections, I probably don't care one bit how bloated a table
> is. Indeed, I care *more* that I'm out of connections and would want to
> know that ASAP

This is a silly argument. When things are failing that's precisely
when you need your monitoring system to work. Of course you are
interested in the fact that you're out of connections but you're
trying to figure out *why* you're out of connections. Maybe you have
queries consuming all iops, maybe disks have filled up and that's
cascaded into a postgres problem, maybe you have lots of similar
queries running, etc.

The first step in debugging is always gathering data which is why it's
so frustrating if the first thing to go down is your monitoring
software.

--
greg

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeremy Harris 2014-01-22 21:20:07 Re: PoC: Duplicate Tuple Elidation during External Sort for DISTINCT
Previous Message Tom Lane 2014-01-22 19:45:00 Re: Patch: Show process IDs of processes holding a lock; show relation and tuple infos of a lock to acquire